[PATCH] ASoC: max98090: request IRQF_ONESHOT interrupt
request_threaded_irq() rejects calls which both do not specify a handler
(indicating that the primary IRQ handler should be used) and do not set
IRQF_ONESHOT because the combination is unsafe with level-triggered
interrupts. It is safe in this case, though, since max98090 IRQs are
edge-triggered and the interrupts aren't ACK'ed until the codec's IRQ
status register is read. Because of this, an IRQF_ONESHOT interrupt
doesn't really make a difference, but request one anyway in order to make
request_threaded_irq() happy.
Signed-off-by: Andrew Bresticker
---
sound/soc/codecs/max98090.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index cbb272b..1bf96bd 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -2247,7 +2247,7 @@ static int max98090_probe(struct snd_soc_codec *codec)
dev_dbg(codec->dev, "irq = %d\n", max98090->irq);
ret = request_threaded_irq(max98090->irq, NULL,
- max98090_interrupt, IRQF_TRIGGER_FALLING,
+ max98090_interrupt, IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
"max98090_interrupt", codec);
if (ret < 0) {
dev_err(codec->dev, "request_irq failed: %d\n",
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: kernel: need extern variable 'screen_info' for related driver using.
Add the extern variable 'screen_info' according to arm32 has done.
The related error:
drivers/video/console/vgacon.c:1305: undefined reference to `screen_info'
Signed-off-by: Chen Gang
---
arch/arm64/kernel/setup.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index add6ea6..1055992 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -374,3 +374,14 @@ const struct seq_operations cpuinfo_op = {
.stop = c_stop,
.show = c_show
};
+
+#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE)
+struct screen_info screen_info = {
+ .orig_video_lines = 30,
+ .orig_video_cols= 80,
+ .orig_video_mode= 0,
+ .orig_video_ega_bx = 0,
+ .orig_video_isVGA = 1,
+ .orig_video_points = 8
+};
+#endif
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 14 May 2013 18:30, Rafael J. Wysocki wrote: > On Tuesday, May 14, 2013 09:36:42 PM Kukjin Kim wrote: >> Viresh Kumar wrote: >> > >> > On 13 May 2013 16:21, Rafael J. Wysocki wrote: >> > > That doesn't matter I suppose. I can take it, but please rebase it on >> > top >> > > of current linux-next. >> > >> > I have already done that (attached). But i wasn't sure what Kukjin wants >> > as >> > he may report conflicts again and i will ask the same question for 3.12 :) >> > >> Since this missed last time, this would be sent to upstream via samsung tree >> again. It means the conflicts should be handled by myself. >> >> Rafael, if you don't mind, let me take this into Samsung tree for v3.11. > > Sure, please go ahead. Kukjin, I hope you have already applied this for linux-next? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lib/mpi/mpicoder.c: looping issue, need stop when equal to zero, found by 'EXTRA_FLAGS=-W'.
For 'while' looping, need stop when 'nbytes == 0', or will cause issue.
('nbytes' is size_t which is always bigger or equal than zero).
The related warning: (with EXTRA_CFLAGS=-W)
lib/mpi/mpicoder.c:40:2: warning: comparison of unsigned expression >= 0 is
always true [-Wtype-limits]
Signed-off-by: Chen Gang
---
lib/mpi/mpicoder.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 5f9c44c..4cc6442 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -37,7 +37,7 @@ MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes)
mpi_limb_t a;
MPI val = NULL;
- while (nbytes >= 0 && buffer[0] == 0) {
+ while (nbytes > 0 && buffer[0] == 0) {
buffer++;
nbytes--;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: kernel 3.10-rc1 p-state/cpuidle panic
Hmm, divide by 0, it seems. + Dirk Brandewie. On Sun, May 19, 2013 at 01:25:41PM +0200, Tommy Apel Hansen wrote: > Hello guys, I'm getting this with the current 3.10-rc1, I've enabled the new > full-NOHZ > I'm not sure though if that has something to do with this or if something is > changed in the > p-state code. > > System : > vendor_id : GenuineIntel > cpu family : 6 > model : 45 > model name : Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz > stepping : 7 > microcode : 0x70b > cpu MHz : 1176.000 > cache size : 10240 KB > physical id : 1 > siblings : 4 > core id : 3 > cpu cores : 4 > apicid: 38 > initial apicid : 38 > fpu : yes > fpu_exception : yes > cpuid level : 13 > wp: yes > flags : [lots of stuff] > bogomips : 4800.56 > clflush size : 64 > cache_alignment : 64 > address sizes : 46 bits physical, 48 bits virtual > power management: > > crash bt: > PID: 0 TASK: 88085c585950 CPU: 5 COMMAND: "swapper/5" > #0 [88107fc83b80] machine_kexec at 8102aad6 > #1 [88107fc83bc0] crash_kexec at 810e57d0 > #2 [88107fc83c90] oops_end at 810073b8 > #3 [88107fc83cb0] do_divide_error at 810040c2 > #4 [88107fc83d50] divide_error at 81637348 > [exception RIP: intel_pstate_timer_func+1071] > RIP: 814f501f RSP: 88107fc83e08 RFLAGS: 00010246 > RAX: RBX: 8808555b9e00 RCX: 8808555b9e40 > RDX: RSI: 0064 RDI: 0001 > RBP: 025debb95955 R8: 8808555b9f70 R9: 03e0 > R10: dead00200200 R11: R12: 001877f8d1d3 > R13: 9a45ae19 R14: 001d27d3d1d8 R15: 0040 > ORIG_RAX: CS: 0010 SS: 0018 > #5 [88107fc83e00] intel_pstate_timer_func at 814f4fa2 > #6 [88107fc83e60] call_timer_fn at 8109edc3 > #7 [88107fc83e90] run_timer_softirq at 810a097e > #8 [88107fc83f10] __do_softirq at 810990f1 > #9 [88107fc83f80] irq_exit at 810993ce > #10 [88107fc83f90] smp_apic_timer_interrupt at 81026448 > #11 [88107fc83fb0] apic_timer_interrupt at 81636eca > --- --- > #12 [88085c587db8] apic_timer_interrupt at 81636eca > [exception RIP: cpuidle_enter_state+72] > RIP: 814f5978 RSP: 88085c587e68 RFLAGS: 0216 > RAX: 0001c61d RBX: 810a11e8 RCX: 0018 > RDX: 000225c17d03 RSI: 88085c587fd8 RDI: 81a12500 > RBP: 0002 R8: 0030 R9: 0001 > R10: R11: R12: 810c48dd > R13: 88085c173950 R14: 0086 R15: > ORIG_RAX: ff10 CS: 0010 SS: 0018 > #13 [88085c587eb0] cpuidle_idle_call at 814f5aca > #14 [88085c587ef0] arch_cpu_idle at 8100cef9 > #15 [88085c587f00] cpu_startup_entry at 810ce5af > > kernel config: > http://pastebin.com/AmEqQNZx > > /Tommy > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2
On Mon, May 20, 2013 at 11:16:33AM +0800, Michael Wang wrote: > I suppose the reason is that the cpu we passed to > mod_delayed_work_on() has a chance to become offline before we > disabled irq, what about check it before send resched ipi? like: I think this is only addressing the symptoms - what we should be doing instead is asking ourselves why are we even scheduling work on a cpu if the machine goes offline? I don't know though who should be responsible for killing all that work - the workqueue itself or the guy who created it, i.e. cpufreq governor... Hmmm. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for May 20
Hi all, Changes since 20130517: The usb.current tree gained a conflict against Linus' tree. The rr-fixes tree gained a build failure so I used the version from next-20130515. The akpm tree gained conflicts against Linus' and the net-next tree. 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 226 trees (counting Linus' and 31 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 (343cd4f Merge tag 'dm-3.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm) Merging fixes/master (0279b3c Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (f66ba56 package: Makefile: unbreak binrpm-pkg target) Merging arc-current/for-curr (81ec684 ARC: [mm] change semantics of __sync_icache_dcache() to inv d$ lines) Merging arm-current/fixes (6eabb33 ARM: 7720/1: ARM v6/v7 cmpxchg64 shouldn't clear upper 32 bits of the old/new value) Merging m68k-current/for-linus (f722406 Linux 3.10-rc1) Merging powerpc-merge/merge (e34166a powerpc: Set show_unhandled_signals to 1 by default) Merging sparc/master (de9c9f8 Merge tag 'remoteproc-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc) Merging net/master (ff0102e net: irda: using kzalloc() instead of kmalloc() to avoid strncpy() issue.) Merging ipsec/master (da241ef Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging sound-current/for-linus (e6135fe ALSA: usb-audio: proc: use found syncmaxsize to determine feedback format) Merging pci-current/for-linus (3f327e3 PCI: acpiphp: Re-enumerate devices when host bridge receives Bus Check) Merging wireless/master (6bb4880 ath9k: fix draining aggregation tid buffers) Merging driver-core.current/driver-core-linus (f722406 Linux 3.10-rc1) Merging tty.current/tty-linus (f722406 Linux 3.10-rc1) Merging usb.current/usb-linus (7138143 USB: ftdi_sio: Add support for Newport CONEX motor drivers) CONFLICT (content): Merge conflict in drivers/usb/host/ohci-nxp.c Merging staging.current/staging-linus (642f2ec staging: dwc2: Fix dma-enabled platform devices using a default dma_mask) Merging char-misc.current/char-misc-linus (221ba15 Char: lp, protect LPGETSTATUS with port_mutex) Merging input-current/for-linus (f0aacea Input: wacom - add a few new styli for Cintiq series) Merging md-current/for-linus (32f9f57 MD: ignore discard request for hard disks of hybid raid1/raid10 array) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (286233e crypto: caam - fix inconsistent assoc dma mapping direction) Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe()) 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 (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (ab28698 of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS) Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error) Merging gpio-current/gpio/merge (e97f9b5
RE: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
> > > >
> > > > am33xx_pinmux: pinmux@44e10800 {
> > > > pinctrl-names = "default";
> > > > - pinctrl-0 = <_keypad_s0 _keys_s0>;
> > > > + pinctrl-0 = <_keypad_s0 _keys_s0
> > > > + _pins_s0>;
> > >
> > > Why add this to the board level fallback (called pinctrl hogs, I think)?
> > > This can be part of nand node you added below so that the pinctrl will
> > > take effect when nand gets probed instead of all the time.
> >
> > Yes we should have all the pinctrl entries under the related drivers.
> > This makes it easy remux pins during runtime if needed, and also
> > allows unloading pinctrl-single.ko for development.
> >
> Yes, accepted. This has been already fixed in v3 of this patch set.
> If all fine, then please pull this for next merge..
>
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/046712.html
>
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/046814.html
>
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/046710.html
>
>
> with regards, pekon
Request you to please accept | provide feedbacks on this patch series.
These are waiting acceptance since Jan-2013, and are necessary for
DT based configs for board having NAND support.
with regards, pekon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with Freescale P1020
Hi Shengzhou/Braun,
We changed the controller init sequence to make this work. I'll submit the
patch upstream soon.
Regards,
Ramneek
-Original Message-
From: Liu Shengzhou-B36685
Sent: Monday, May 20, 2013 9:07 AM
To: Michael Braun; Mehresh Ramneek-B31383
Cc: projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman;
linux-...@vger.kernel.org; Alan Stern; linux-kernel@vger.kernel.org
Subject: RE: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with
Freescale P1020
Hi Braun,
At that time I had an P4080DS board which had the same issue and had been fixed
with this patch.
I didn't test it on P1020 due to the absence of P1020. I think P1020 will need
a new patch besides this one.
Later Ramneek took this issue on P1020 for more investigation.
Hello Ramneek, any update for the PHY_CLK_VALID issue?
Regards,
Shengzhou
> -Original Message-
> From: Michael Braun [mailto:michael.br...@fem.tu-ilmenau.de]
> Sent: Sunday, May 19, 2013 11:23 PM
> To: Liu Shengzhou-B36685
> Cc: projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org; Alan Stern; linux-kernel@vger.kernel.org
> Subject: Re: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884
> with Freescale P1020
>
> Hi,
>
> I've got hardware here to test with, so if there any changes to test,
> I'm willing to support.
> Meanwhile, might it be a good idea to make that check optional - i.e.
> add a module parameter or something like this around it?
>
> Regards,
> M. Braun
>
> On Thu, Apr 18, 2013 at 05:13:39PM +0200, michael-dev wrote:
> > Hi,
> >
> > thanks for the quick reply.
> >
> > >Please review the patch http://patchwork.ozlabs.org/patch/237201/
> > I applied it, but it does not make any difference on my platform.
> >
> > Regards,
> > M. Braun
> >
> > Am 17.04.2013 12:53, schrieb Liu Shengzhou-B36685:
> > >Hi Braun,
> > >
> > >It seems the duplicated tdi_reset caused the PHY_CLK_VALID bit
> > >unstable, introduced by patch "EHCI: centralize controller
> > >initialization".
> > >I submitted a patch to fix it.
> > >Please review the patch http://patchwork.ozlabs.org/patch/237201/
> > >
> > >Regards,
> > >Shengzhou
> > >
> > >
> > >>-Original Message-
> > >>From: Michael Braun [mailto:michael-...@fami-braun.de]
> > >>Sent: Wednesday, April 17, 2013 6:08 PM
> > >>To: Liu Shengzhou-B36685
> > >>Cc: Alan Stern; projekt-w...@fem.tu-ilmenau.de; Greg
> > >>Kroah-Hartman; linux-...@vger.kernel.org;
> > >>linux-kernel@vger.kernel.org
> > >>Subject: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884
> > >>with Freescale P1020
> > >>
> > >>Hi,
> > >>
> > >>I'm running OpenWRT Kernel 3.8.3 (which already has
> > >>f66dea709cd9309b2ee9f715697818001fb518de and
> > >>5ed338778f917a035f0f0a52327fc4f72e36f7a1 applied) on a P1020WLAN
> > >>(QorlQ,
> > >>PPC) device.
> > >>Before updating the kernel from 3.3.0, USB host support was
> > >>working fine.
> > >>Now I get "fsl-ehci: USB PHY clock invalid" messages in dmesg and
> > >>the lsusb output is empty, so USB host support is not working.
> > >>When I apply the following patch, USB host support starts working
> > >>again, so I guess
> > >>3735ba8db8e6ea22ad3ff524328926d8d780a884 is the cause.
> > >>Do you have an idea how to fix it more appropriately?
> > >>
> > >>Thanks,
> > >> M. Braun
> > >>
> > >>--- a/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:52.924403077
> > >>+0200
> > >>+++ b/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:57.572410838
> > >>+0200
> > >>@@ -273,7 +273,6 @@ static int ehci_fsl_setup_phy(struct usb
> > >> if (!spin_event_timeout(in_be32(non_ehci +
> > >>FSL_SOC_USB_CTRL) &
> > >> PHY_CLK_VALID,
> > >>FSL_USB_PHY_CLK_TIMEOUT,
> > >>0)) {
> > >> printk(KERN_WARNING "fsl-ehci: USB PHY
> > >>clock invalid\n");
> > >>- return -EINVAL;
> > >> }
> > >> }
> > >>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 17/18] cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
On 13 May 2013 11:34, Viresh Kumar wrote: > On 22 April 2013 12:19, Viresh Kumar wrote: >> On 9 April 2013 14:05, Viresh Kumar wrote: >>> On 5 April 2013 12:16, Viresh Kumar wrote: On 4 April 2013 18:24, Viresh Kumar wrote: > This patch moves cpufreq driver of powerpc platform to drivers/cpufreq. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Olof Johansson > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: Viresh Kumar > --- > Compile Tested only. > > arch/powerpc/platforms/Kconfig | 31 > -- > arch/powerpc/platforms/pasemi/Makefile | 1 - > arch/powerpc/platforms/powermac/Makefile | 2 -- > drivers/cpufreq/Kconfig.powerpc| 26 > ++ > drivers/cpufreq/Makefile | 3 +++ > .../cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c | 0 > .../cpufreq/pmac32-cpufreq.c | 0 > .../cpufreq/pmac64-cpufreq.c | 0 > 8 files changed, 29 insertions(+), 34 deletions(-) > rename arch/powerpc/platforms/pasemi/cpufreq.c => > drivers/cpufreq/pasemi-cpufreq.c (100%) > rename arch/powerpc/platforms/powermac/cpufreq_32.c => > drivers/cpufreq/pmac32-cpufreq.c (100%) > rename arch/powerpc/platforms/powermac/cpufreq_64.c => > drivers/cpufreq/pmac64-cpufreq.c (100%) Hi Deepthi, Can you help testing this please? >>> >>> Ping!! >> >> Ping!! > > Hi Benjamin, > > Hope you are back from your vacations. Can you give it a try now? Ping!! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory
On 20 May 2013 00:13, Francesco Lavra wrote:
> On 05/17/2013 01:26 PM, Viresh Kumar wrote:
>> +EXPORT_SYMBOL(get_cpufreq_global_kobject);
>> +EXPORT_SYMBOL(put_cpufreq_global_kobject);
>
> Global symbol names should begin with a sensible prefix; in this case,
> it looks like cpufreq_get_global_kobject and cpufreq_put_global_kobject
> would be more appropriate names.
Please see if V2 looks fine. Attached too for applying.
xx--
From: Viresh Kumar
Date: Fri, 17 May 2013 16:09:09 +0530
Subject: [PATCH V2] cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq
directory
When we don't have any file in cpu/cpufreq directory we shouldn't create it.
Specially with the introduction of per-policy governor instance patchset, even
governors are moved to cpu/cpu*/cpufreq/governor-name directory and so this
directory is just not required.
Lets have it only when required.
Signed-off-by: Viresh Kumar
---
V1->V2: Replace: {get|put}_cpufreq_global_kobject with
cpufreq_{get|put}_global_kobject.
drivers/cpufreq/acpi-cpufreq.c | 4 ++--
drivers/cpufreq/cpufreq.c | 48 ++
drivers/cpufreq/cpufreq_governor.c | 6 +
include/linux/cpufreq.h| 4
4 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index ce28c34..ae0918d 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -947,7 +947,7 @@ static void __init acpi_cpufreq_boost_init(void)
/* We create the boost file in any case, though for systems without
* hardware support it will be read-only and hardwired to return 0.
*/
- if (sysfs_create_file(cpufreq_global_kobject, &(global_boost.attr)))
+ if (cpufreq_sysfs_create_file(&(global_boost.attr)))
pr_warn(PFX "could not register global boost sysfs file\n");
else
pr_debug("registered global boost sysfs file\n");
@@ -955,7 +955,7 @@ static void __init acpi_cpufreq_boost_init(void)
static void __exit acpi_cpufreq_boost_exit(void)
{
- sysfs_remove_file(cpufreq_global_kobject, &(global_boost.attr));
+ cpufreq_sysfs_remove_file(&(global_boost.attr));
if (msrs) {
unregister_cpu_notifier(_nb);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e3d7112..74a1a60 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -678,9 +678,6 @@ static struct attribute *default_attrs[] = {
NULL
};
-struct kobject *cpufreq_global_kobject;
-EXPORT_SYMBOL(cpufreq_global_kobject);
-
#define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
#define to_attr(a) container_of(a, struct freq_attr, attr)
@@ -751,6 +748,49 @@ static struct kobj_type ktype_cpufreq = {
.release= cpufreq_sysfs_release,
};
+struct kobject *cpufreq_global_kobject;
+EXPORT_SYMBOL(cpufreq_global_kobject);
+
+static int cpufreq_global_kobject_usage;
+
+int cpufreq_get_global_kobject(void)
+{
+ if (!cpufreq_global_kobject_usage++)
+ return kobject_add(cpufreq_global_kobject,
+ _subsys.dev_root->kobj, "%s", "cpufreq");
+
+ return 0;
+}
+EXPORT_SYMBOL(cpufreq_get_global_kobject);
+
+void cpufreq_put_global_kobject(void)
+{
+ if (!--cpufreq_global_kobject_usage)
+ kobject_del(cpufreq_global_kobject);
+}
+EXPORT_SYMBOL(cpufreq_put_global_kobject);
+
+int cpufreq_sysfs_create_file(const struct attribute *attr)
+{
+ int ret = cpufreq_get_global_kobject();
+
+ if (!ret) {
+ ret = sysfs_create_file(cpufreq_global_kobject, attr);
+ if (ret)
+ cpufreq_put_global_kobject();
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(cpufreq_sysfs_create_file);
+
+void cpufreq_sysfs_remove_file(const struct attribute *attr)
+{
+ sysfs_remove_file(cpufreq_global_kobject, attr);
+ cpufreq_put_global_kobject();
+}
+EXPORT_SYMBOL(cpufreq_sysfs_remove_file);
+
/* symlink affected CPUs */
static int cpufreq_add_dev_symlink(unsigned int cpu,
struct cpufreq_policy *policy)
@@ -2022,7 +2062,7 @@ static int __init cpufreq_core_init(void)
init_rwsem(_cpu(cpu_policy_rwsem, cpu));
}
- cpufreq_global_kobject = kobject_create_and_add("cpufreq",
_subsys.dev_root->kobj);
+ cpufreq_global_kobject = kobject_create();
BUG_ON(!cpufreq_global_kobject);
register_syscore_ops(_syscore_ops);
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index b6cfd55..7532570 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -231,6 +231,9 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
return rc;
}
+ if (!have_governor_per_policy())
+
[PATCH] arm64: compiling issue for allmodconfig, need "asm/parport.h" by "drivers/parport/parport_pc.c"
Need add the default file in 'asm/Kbuild' just like arm has done. The build command is: make EXTRA_CFLAGS=-W ARCH=arm64 allmodconfig make EXTRA_CFLAGS=-W ARCH=arm64 menuconfig set "aarch64-linux-gnu-" as cross compiling prefix. make EXTRA_CFLAGS=-W ARCH=arm64 The related error: drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such file or directory Signed-off-by: Chen Gang --- arch/arm64/include/asm/Kbuild |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild index 79a642d..9005e81 100644 --- a/arch/arm64/include/asm/Kbuild +++ b/arch/arm64/include/asm/Kbuild @@ -25,6 +25,7 @@ generic-y += local64.h generic-y += mman.h generic-y += msgbuf.h generic-y += mutex.h +generic-y += parport.h generic-y += pci.h generic-y += percpu.h generic-y += poll.h -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory
On 20 May 2013 00:13, Francesco Lavra wrote: > On 05/17/2013 01:26 PM, Viresh Kumar wrote: >> +EXPORT_SYMBOL(get_cpufreq_global_kobject); >> +EXPORT_SYMBOL(put_cpufreq_global_kobject); > > Global symbol names should begin with a sensible prefix; in this case, > it looks like cpufreq_get_global_kobject and cpufreq_put_global_kobject > would be more appropriate names. Sure. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the usb.current tree with Linus' tree
On Mon, May 20, 2013 at 10:21:59AM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb.current tree got a conflict in
> drivers/usb/host/ohci-nxp.c between commit bb522812a1a6
> ("drivers/usb/host: don't check resource with devm_ioremap_resource")
> from Linus' tree and commit b3517d5de80e ("usb: ohci: fix goto wrong tag
> in err case") from the usb.current tree.
>
> The former remove a bit of code modified by the latter, so I did that and
> can carry the fix as necessary (no action is required).
Sounds fine to me, 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/
linux-next: manual merge of the akpm tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/net/bpf_jit_comp.c between commit 650c8496702f ("x86:
bpf_jit_comp: can call module_free() from any context") from the net-next
tree and commit "bpf: add comments explaining the schedule_work()
operation" from the akpm tree.
The former means that the latter is no longer needed, so I used the
former and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpYRzuJ6KAtU.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/sparc/net/bpf_jit_comp.c between commit 5199dfe531db ("sparc:
bpf_jit_comp: can call module_free() from any context") from the net-next
tree and commit "bpf: add comments explaining the schedule_work()
operation" from the akpm tree.
The former means that the latter is no longer reqired, so I used the
former and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpkWBo8Xsp2_.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in
fs/btrfs/inode.c and fs/btrfs/volumes.c between commit 9be3395bcd4a
("Btrfs: use a btrfs bioset instead of abusing bio internals") from
Linus' tree and commit "block: prep work for batch completion" from the
akpm tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
I also noticed that a single conversion of bio_endio to bio_endio_batch
is done in the akpm patch but bio_endio_batch is not introduced until a
later patch ... :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/btrfs/inode.c
index af978f7,551c8bd..000
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@@ -6932,14 -6928,11 +6932,15 @@@ struct btrfs_dio_private
/* IO errors */
int errors;
+ /* orig_bio is our btrfs_io_bio */
struct bio *orig_bio;
+
+ /* dio_bio came from fs/direct-io.c */
+ struct bio *dio_bio;
};
- static void btrfs_endio_direct_read(struct bio *bio, int err)
+ static void btrfs_endio_direct_read(struct bio *bio, int err,
+ struct batch_complete *batch)
{
struct btrfs_dio_private *dip = bio->bi_private;
struct bio_vec *bvec_end = bio->bi_io_vec + bio->bi_vcnt - 1;
@@@ -6992,12 -6984,12 +6993,13 @@@ failed
/* If we had a csum failure make sure to clear the uptodate flag */
if (err)
- clear_bit(BIO_UPTODATE, >bi_flags);
- dio_end_io(bio, err, batch);
+ clear_bit(BIO_UPTODATE, _bio->bi_flags);
- dio_end_io(dio_bio, err);
++ dio_end_io(dio_bio, err, batch);
+ bio_put(bio);
}
- static void btrfs_endio_direct_write(struct bio *bio, int err)
+ static void btrfs_endio_direct_write(struct bio *bio, int err,
+struct batch_complete *batch)
{
struct btrfs_dio_private *dip = bio->bi_private;
struct inode *inode = dip->inode;
@@@ -7039,9 -7030,8 +7041,9 @@@ out_done
/* If we had an error make sure to clear the uptodate flag */
if (err)
- clear_bit(BIO_UPTODATE, >bi_flags);
- dio_end_io(bio, err, batch);
+ clear_bit(BIO_UPTODATE, _bio->bi_flags);
- dio_end_io(dio_bio, err);
++ dio_end_io(dio_bio, err, batch);
+ bio_put(bio);
}
static int __btrfs_submit_bio_start_direct_io(struct inode *inode, int rw,
diff --cc fs/btrfs/volumes.c
index 8bffb91,7299b55..000
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@@ -5018,9 -5019,35 +5018,10 @@@ int btrfs_rmap_block(struct btrfs_mappi
return 0;
}
- static void btrfs_end_bio(struct bio *bio, int err)
-static void *merge_stripe_index_into_bio_private(void *bi_private,
- unsigned int stripe_index)
-{
- /*
- * with single, dup, RAID0, RAID1 and RAID10, stripe_index is
- * at most 1.
- * The alternative solution (instead of stealing bits from the
- * pointer) would be to allocate an intermediate structure
- * that contains the old private pointer plus the stripe_index.
- */
- BUG_ONuintptr_t)bi_private) & 3) != 0);
- BUG_ON(stripe_index > 3);
- return (void *)(((uintptr_t)bi_private) | stripe_index);
-}
-
-static struct btrfs_bio *extract_bbio_from_bio_private(void *bi_private)
-{
- return (struct btrfs_bio *)(((uintptr_t)bi_private) & ~((uintptr_t)3));
-}
-
-static unsigned int extract_stripe_index_from_bio_private(void *bi_private)
-{
- return (unsigned int)((uintptr_t)bi_private) & 3;
-}
-
+ static void btrfs_end_bio(struct bio *bio, int err,
+ struct batch_complete *batch)
{
- struct btrfs_bio *bbio = extract_bbio_from_bio_private(bio->bi_private);
+ struct btrfs_bio *bbio = bio->bi_private;
int is_orig_bio = 0;
if (err) {
pgpZ9r75T9sP9.pgp
Description: PGP signature
[PATCH] MAINTAINERS: Add myself as maintainer for LM95234 and TMP401 drivers
I wrote the LM95234 driver and extended the TMP401 driver substantially, and I have hardware to test both, so it makes sense to explicitly maintain them. Signed-off-by: Guenter Roeck --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3d7782b..f0f3d20 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4976,6 +4976,13 @@ S: Maintained F: Documentation/hwmon/lm90 F: drivers/hwmon/lm90.c +LM95234 HARDWARE MONITOR DRIVER +M: Guenter Roeck +L: lm-sens...@lm-sensors.org +S: Maintained +F: Documentation/hwmon/lm95234 +F: drivers/hwmon/lm95234.c + LME2510 MEDIA DRIVER M: Malcolm Priestley L: linux-me...@vger.kernel.org @@ -8182,6 +8189,13 @@ F: drivers/mmc/host/sh_mobile_sdhi.c F: include/linux/mmc/tmio.h F: include/linux/mmc/sh_mobile_sdhi.h +TMP401 HARDWARE MONITOR DRIVER +M: Guenter Roeck +L: lm-sens...@lm-sensors.org +S: Maintained +F: Documentation/hwmon/tmp401 +F: drivers/hwmon/tmp401.c + TMPFS (SHMEM FILESYSTEM) M: Hugh Dickins L: linux...@kvack.org -- 1.7.9.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with Freescale P1020
Hi Braun,
At that time I had an P4080DS board which had the same issue and had been fixed
with this patch.
I didn't test it on P1020 due to the absence of P1020. I think P1020 will need
a new patch besides this one.
Later Ramneek took this issue on P1020 for more investigation.
Hello Ramneek, any update for the PHY_CLK_VALID issue?
Regards,
Shengzhou
> -Original Message-
> From: Michael Braun [mailto:michael.br...@fem.tu-ilmenau.de]
> Sent: Sunday, May 19, 2013 11:23 PM
> To: Liu Shengzhou-B36685
> Cc: projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org; Alan Stern; linux-kernel@vger.kernel.org
> Subject: Re: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with
> Freescale P1020
>
> Hi,
>
> I've got hardware here to test with, so if there any changes to test, I'm
> willing to support.
> Meanwhile, might it be a good idea to make that check optional - i.e. add
> a module parameter or something like this around it?
>
> Regards,
> M. Braun
>
> On Thu, Apr 18, 2013 at 05:13:39PM +0200, michael-dev wrote:
> > Hi,
> >
> > thanks for the quick reply.
> >
> > >Please review the patch http://patchwork.ozlabs.org/patch/237201/
> > I applied it, but it does not make any difference on my platform.
> >
> > Regards,
> > M. Braun
> >
> > Am 17.04.2013 12:53, schrieb Liu Shengzhou-B36685:
> > >Hi Braun,
> > >
> > >It seems the duplicated tdi_reset caused the PHY_CLK_VALID bit
> > >unstable, introduced by patch "EHCI: centralize controller
> > >initialization".
> > >I submitted a patch to fix it.
> > >Please review the patch http://patchwork.ozlabs.org/patch/237201/
> > >
> > >Regards,
> > >Shengzhou
> > >
> > >
> > >>-Original Message-
> > >>From: Michael Braun [mailto:michael-...@fami-braun.de]
> > >>Sent: Wednesday, April 17, 2013 6:08 PM
> > >>To: Liu Shengzhou-B36685
> > >>Cc: Alan Stern; projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman;
> > >>linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> > >>Subject: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with
> > >>Freescale P1020
> > >>
> > >>Hi,
> > >>
> > >>I'm running OpenWRT Kernel 3.8.3 (which already has
> > >>f66dea709cd9309b2ee9f715697818001fb518de and
> > >>5ed338778f917a035f0f0a52327fc4f72e36f7a1 applied) on a P1020WLAN
> > >>(QorlQ,
> > >>PPC) device.
> > >>Before updating the kernel from 3.3.0, USB host support was working
> > >>fine.
> > >>Now I get "fsl-ehci: USB PHY clock invalid" messages in dmesg and
> > >>the lsusb output is empty, so USB host support is not working. When
> > >>I apply the following patch, USB host support starts working again,
> > >>so I guess
> > >>3735ba8db8e6ea22ad3ff524328926d8d780a884 is the cause.
> > >>Do you have an idea how to fix it more appropriately?
> > >>
> > >>Thanks,
> > >> M. Braun
> > >>
> > >>--- a/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:52.924403077
> > >>+0200
> > >>+++ b/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:57.572410838
> > >>+0200
> > >>@@ -273,7 +273,6 @@ static int ehci_fsl_setup_phy(struct usb
> > >> if (!spin_event_timeout(in_be32(non_ehci +
> > >>FSL_SOC_USB_CTRL) &
> > >> PHY_CLK_VALID,
> > >>FSL_USB_PHY_CLK_TIMEOUT,
> > >>0)) {
> > >> printk(KERN_WARNING "fsl-ehci: USB PHY
> > >>clock invalid\n");
> > >>- return -EINVAL;
> > >> }
> > >> }
> > >>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/15] f2fs: remove unnecessary flag set
If an inode is recovered with its dentry, it will not invoke __f2fs_add_link,
since the recovery routine checks its dentry before calling __f2fs_add_link.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 2941987..993b601 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -125,11 +125,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
goto next;
entry = get_fsync_inode(head, ino_of_node(page));
- if (entry) {
- if (IS_INODE(page) && is_dent_dnode(page))
- set_inode_flag(F2FS_I(entry->inode),
- FI_INC_LINK);
- } else {
+ if (!entry) {
if (IS_INODE(page) && is_dent_dnode(page)) {
err = recover_inode_page(sbi, page);
if (err)
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/15] f2fs: remove redundant assignment
We don't need to assign a value redundantly.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 60c8a50..2941987 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -126,7 +126,6 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
entry = get_fsync_inode(head, ino_of_node(page));
if (entry) {
- entry->blkaddr = blkaddr;
if (IS_INODE(page) && is_dent_dnode(page))
set_inode_flag(F2FS_I(entry->inode),
FI_INC_LINK);
@@ -150,10 +149,10 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
kmem_cache_free(fsync_entry_slab, entry);
goto unlock_out;
}
-
list_add_tail(>list, head);
- entry->blkaddr = blkaddr;
}
+ entry->blkaddr = blkaddr;
+
if (IS_INODE(page)) {
err = recover_inode(entry->inode, page);
if (err == -ENOENT) {
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/15] f2fs: remove unnecessary por_doing check
This por_doing check is totally not related to the recovery process. Signed-off-by: Jaegeuk Kim --- fs/f2fs/namei.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 47abc97..729b285 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -149,8 +149,7 @@ static int f2fs_create(struct inode *dir, struct dentry *dentry, umode_t mode, alloc_nid_done(sbi, ino); - if (!sbi->por_doing) - d_instantiate(dentry, inode); + d_instantiate(dentry, inode); unlock_new_inode(inode); return 0; out: -- 1.8.1.3.566.gaa39828 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/15] f2fs: fix por_doing variable coverage
The reason of using sbi->por_doing is to alleviate data writes during the recovery. The find_fsync_dnodes() produces some dirty dentry pages, so we should cover it too with sbi->por_doing. Signed-off-by: Jaegeuk Kim --- fs/f2fs/recovery.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index 993b601..f77aedd 100644 --- a/fs/f2fs/recovery.c +++ b/fs/f2fs/recovery.c @@ -377,6 +377,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi) INIT_LIST_HEAD(_list); /* step #1: find fsynced inode numbers */ + sbi->por_doing = 1; err = find_fsync_dnodes(sbi, _list); if (err) goto out; @@ -385,13 +386,12 @@ int recover_fsync_data(struct f2fs_sb_info *sbi) goto out; /* step #2: recover data */ - sbi->por_doing = 1; err = recover_data(sbi, _list, CURSEG_WARM_NODE); - sbi->por_doing = 0; BUG_ON(!list_empty(_list)); out: destroy_fsync_dnodes(sbi, _list); kmem_cache_destroy(fsync_entry_slab); + sbi->por_doing = 0; write_checkpoint(sbi, false); return err; } -- 1.8.1.3.566.gaa39828 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/15] f2fs: update inode page after creation
I found a bug when testing power-off-recovery as follows.
[Bug Scenario]
1. create a file
2. fsync the file
3. reboot w/o any sync
4. try to recover the file
- found its fsync mark
- found its dentry mark
: try to recover its dentry
- get its file name
- get its parent inode number
: here we got zero value
The reason why we get the wrong parent inode number is that we didn't
synchronize the inode page with its newly created inode information perfectly.
Especially, previous f2fs stores fi->i_pino and writes it to the cached
node page in a wrong order, which incurs the zero-valued i_pino during the
recovery.
So, this patch modifies the creation flow to fix the synchronization order of
inode page with its inode.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 1 +
fs/f2fs/dir.c | 85 +++---
fs/f2fs/f2fs.h | 3 +--
fs/f2fs/node.c | 12 +++--
4 files changed, 51 insertions(+), 50 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index af74549..c320f7f 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -279,6 +279,7 @@ repeat:
*
* Also, caller should grab and release a mutex by calling mutex_lock_op() and
* mutex_unlock_op().
+ * Note that, npage is set only by make_empty_dir.
*/
struct page *get_new_data_page(struct inode *inode,
struct page *npage, pgoff_t index, bool new_i_size)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 7db6e58..fc1dacf 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -264,15 +264,10 @@ void f2fs_set_link(struct inode *dir, struct
f2fs_dir_entry *de,
f2fs_put_page(page, 1);
}
-void init_dent_inode(const struct qstr *name, struct page *ipage)
+static void init_dent_inode(const struct qstr *name, struct page *ipage)
{
struct f2fs_node *rn;
- if (IS_ERR(ipage))
- return;
-
- wait_on_page_writeback(ipage);
-
/* copy name info. to this inode page */
rn = (struct f2fs_node *)page_address(ipage);
rn->i.i_namelen = cpu_to_le32(name->len);
@@ -280,14 +275,15 @@ void init_dent_inode(const struct qstr *name, struct page
*ipage)
set_page_dirty(ipage);
}
-static int make_empty_dir(struct inode *inode, struct inode *parent)
+static int make_empty_dir(struct inode *inode,
+ struct inode *parent, struct page *page)
{
struct page *dentry_page;
struct f2fs_dentry_block *dentry_blk;
struct f2fs_dir_entry *de;
void *kaddr;
- dentry_page = get_new_data_page(inode, NULL, 0, true);
+ dentry_page = get_new_data_page(inode, page, 0, true);
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
@@ -317,42 +313,47 @@ static int make_empty_dir(struct inode *inode, struct
inode *parent)
return 0;
}
-static int init_inode_metadata(struct inode *inode,
+static struct page *init_inode_metadata(struct inode *inode,
struct inode *dir, const struct qstr *name)
{
+ struct page *page;
+ int err;
+
if (is_inode_flag_set(F2FS_I(inode), FI_NEW_INODE)) {
- int err;
- err = new_inode_page(inode, name);
- if (err)
- return err;
+ page = new_inode_page(inode, name);
+ if (IS_ERR(page))
+ return page;
if (S_ISDIR(inode->i_mode)) {
- err = make_empty_dir(inode, dir);
- if (err) {
- remove_inode_page(inode);
- return err;
- }
+ err = make_empty_dir(inode, dir, page);
+ if (err)
+ goto error;
}
err = f2fs_init_acl(inode, dir);
- if (err) {
- remove_inode_page(inode);
- return err;
- }
+ if (err)
+ goto error;
+
+ wait_on_page_writeback(page);
} else {
- struct page *ipage;
- ipage = get_node_page(F2FS_SB(dir->i_sb), inode->i_ino);
- if (IS_ERR(ipage))
- return PTR_ERR(ipage);
- set_cold_node(inode, ipage);
- init_dent_inode(name, ipage);
- f2fs_put_page(ipage, 1);
+ page = get_node_page(F2FS_SB(dir->i_sb), inode->i_ino);
+ if (IS_ERR(page))
+ return page;
+
+ wait_on_page_writeback(page);
+ set_cold_node(inode, page);
}
- if (is_inode_flag_set(F2FS_I(inode), FI_INC_LINK)) {
+
+ init_dent_inode(name, page);
+
+ if (is_inode_flag_set(F2FS_I(inode), FI_INC_LINK))
inc_nlink(inode);
- update_inode_page(inode);
- }
- return 0;
+ return page;
+
+error:
+
[PATCH 06/15] f2fs: skip get_node_page if locked node page is passed
If get_dnode_of_data gets a locked node page, let's skip redundant
get_node_page calls.
This is for the futher enhancement.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/node.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 9641534..f63f0a4 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -408,10 +408,13 @@ int get_dnode_of_data(struct dnode_of_data *dn, pgoff_t
index, int mode)
level = get_node_path(index, offset, noffset);
nids[0] = dn->inode->i_ino;
- npage[0] = get_node_page(sbi, nids[0]);
- if (IS_ERR(npage[0]))
- return PTR_ERR(npage[0]);
+ npage[0] = dn->inode_page;
+ if (!npage[0]) {
+ npage[0] = get_node_page(sbi, nids[0]);
+ if (IS_ERR(npage[0]))
+ return PTR_ERR(npage[0]);
+ }
parent = npage[0];
if (level != 0)
nids[1] = get_nid(parent, offset[0], true);
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/15] f2fs: fix BUG_ON during f2fs_evict_inode(dir)
During the dentry recovery routine, recover_inode() triggers __f2fs_add_link
with its directory inode.
In the following scenario, a bug is captured.
1. dir = f2fs_iget(pino)
2. __f2fs_add_link(dir, name)
3. iput(dir)
-> f2fs_evict_inode() faces with BUG_ON(atomic_read(fi->dirty_dents))
Kernel BUG at a01c0676 [verbose debug info unavailable]
[] f2fs_evict_inode+0x276/0x300 [f2fs]
Call Trace:
[] evict+0xb0/0x1b0
[] iput+0x105/0x190
[] recover_fsync_data+0x3bc/0x1070 [f2fs]
[] ? io_schedule+0xaa/0xd0
[] ? __wait_on_bit_lock+0x7b/0xc0
[] ? __lock_page+0x67/0x70
[] ? kmem_cache_alloc+0x31/0x140
[] ? __d_instantiate+0x92/0xf0
[] ? security_d_instantiate+0x1b/0x30
[] ? d_instantiate+0x54/0x70
This means that we should flush all the dentry pages between iget and iput().
But, during the recovery routine, it is unallowed due to consistency, so we
have to wait the whole recovery process.
And then, write_checkpoint flushes all the dirty dentry blocks, and nicely we
can put the stale dir inodes from the dirty_dir_inode_list.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c | 23 +++
fs/f2fs/f2fs.h | 2 ++
fs/f2fs/recovery.c | 14 +-
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index b1de01d..3d11449 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -514,6 +514,29 @@ void remove_dirty_dir_inode(struct inode *inode)
}
out:
spin_unlock(>dir_inode_lock);
+
+ /* Only from the recovery routine */
+ if (is_inode_flag_set(F2FS_I(inode), FI_DELAY_IPUT))
+ iput(inode);
+}
+
+struct inode *check_dirty_dir_inode(struct f2fs_sb_info *sbi, nid_t ino)
+{
+ struct list_head *head = >dir_inode_list;
+ struct list_head *this;
+ struct inode *inode = NULL;
+
+ spin_lock(>dir_inode_lock);
+ list_for_each(this, head) {
+ struct dir_inode_entry *entry;
+ entry = list_entry(this, struct dir_inode_entry, list);
+ if (entry->inode->i_ino == ino) {
+ inode = entry->inode;
+ break;
+ }
+ }
+ spin_unlock(>dir_inode_lock);
+ return inode;
}
void sync_dirty_dir_inodes(struct f2fs_sb_info *sbi)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 20aab02..ef6cac8 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -846,6 +846,7 @@ enum {
FI_INC_LINK,/* need to increment i_nlink */
FI_ACL_MODE,/* indicate acl mode */
FI_NO_ALLOC,/* should not allocate any blocks */
+ FI_DELAY_IPUT, /* used for the recovery */
};
static inline void set_inode_flag(struct f2fs_inode_info *fi, int flag)
@@ -1012,6 +1013,7 @@ int recover_orphan_inodes(struct f2fs_sb_info *);
int get_valid_checkpoint(struct f2fs_sb_info *);
void set_dirty_dir_page(struct inode *, struct page *);
void remove_dirty_dir_inode(struct inode *);
+struct inode *check_dirty_dir_inode(struct f2fs_sb_info *, nid_t);
void sync_dirty_dir_inodes(struct f2fs_sb_info *);
void write_checkpoint(struct f2fs_sb_info *, bool);
void init_orphan_info(struct f2fs_sb_info *);
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index f77aedd..c573944 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -42,6 +42,7 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
{
struct f2fs_node *raw_node = (struct f2fs_node *)kmap(ipage);
struct f2fs_inode *raw_inode = &(raw_node->i);
+ nid_t pino = le32_to_cpu(raw_inode->i_pino);
struct qstr name;
struct f2fs_dir_entry *de;
struct page *page;
@@ -51,10 +52,14 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
if (!is_dent_dnode(ipage))
goto out;
- dir = f2fs_iget(inode->i_sb, le32_to_cpu(raw_inode->i_pino));
- if (IS_ERR(dir)) {
- err = PTR_ERR(dir);
- goto out;
+ dir = check_dirty_dir_inode(F2FS_SB(inode->i_sb), pino);
+ if (!dir) {
+ dir = f2fs_iget(inode->i_sb, pino);
+ if (IS_ERR(dir)) {
+ err = PTR_ERR(dir);
+ goto out;
+ }
+ set_inode_flag(F2FS_I(dir), FI_DELAY_IPUT);
}
name.len = le32_to_cpu(raw_inode->i_namelen);
@@ -67,7 +72,6 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
} else {
err = __f2fs_add_link(dir, , inode);
}
- iput(dir);
out:
kunmap(ipage);
return err;
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/15] f2fs: change get_new_data_page to pass a locked node page
This patch is for passing a locked node page to get_dnode_of_data.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 12 +++-
fs/f2fs/dir.c | 4 ++--
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/file.c | 2 +-
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 05fb5c6..af74549 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -280,8 +280,8 @@ repeat:
* Also, caller should grab and release a mutex by calling mutex_lock_op() and
* mutex_unlock_op().
*/
-struct page *get_new_data_page(struct inode *inode, pgoff_t index,
- bool new_i_size)
+struct page *get_new_data_page(struct inode *inode,
+ struct page *npage, pgoff_t index, bool new_i_size)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
struct address_space *mapping = inode->i_mapping;
@@ -289,18 +289,20 @@ struct page *get_new_data_page(struct inode *inode,
pgoff_t index,
struct dnode_of_data dn;
int err;
- set_new_dnode(, inode, NULL, NULL, 0);
+ set_new_dnode(, inode, npage, npage, 0);
err = get_dnode_of_data(, index, ALLOC_NODE);
if (err)
return ERR_PTR(err);
if (dn.data_blkaddr == NULL_ADDR) {
if (reserve_new_block()) {
- f2fs_put_dnode();
+ if (!npage)
+ f2fs_put_dnode();
return ERR_PTR(-ENOSPC);
}
}
- f2fs_put_dnode();
+ if (!npage)
+ f2fs_put_dnode();
repeat:
page = grab_cache_page(mapping, index);
if (!page)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 1ac6b93..7db6e58 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -287,7 +287,7 @@ static int make_empty_dir(struct inode *inode, struct inode
*parent)
struct f2fs_dir_entry *de;
void *kaddr;
- dentry_page = get_new_data_page(inode, 0, true);
+ dentry_page = get_new_data_page(inode, NULL, 0, true);
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
@@ -448,7 +448,7 @@ start:
bidx = dir_block_index(level, (le32_to_cpu(dentry_hash) % nbucket));
for (block = bidx; block <= (bidx + nblock - 1); block++) {
- dentry_page = get_new_data_page(dir, block, true);
+ dentry_page = get_new_data_page(dir, NULL, block, true);
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index ef6cac8..cbae2b6 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1027,7 +1027,7 @@ int reserve_new_block(struct dnode_of_data *);
void update_extent_cache(block_t, struct dnode_of_data *);
struct page *find_data_page(struct inode *, pgoff_t, bool);
struct page *get_lock_data_page(struct inode *, pgoff_t);
-struct page *get_new_data_page(struct inode *, pgoff_t, bool);
+struct page *get_new_data_page(struct inode *, struct page *, pgoff_t, bool);
int f2fs_readpage(struct f2fs_sb_info *, struct page *, block_t, int);
int do_write_data_page(struct page *);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 1cae864..b8e34db 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -387,7 +387,7 @@ static void fill_zero(struct inode *inode, pgoff_t index,
f2fs_balance_fs(sbi);
ilock = mutex_lock_op(sbi);
- page = get_new_data_page(inode, index, false);
+ page = get_new_data_page(inode, NULL, index, false);
mutex_unlock_op(sbi, ilock);
if (!IS_ERR(page)) {
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/15] f2fs: add debug msgs in the recovery routine
This patch adds some trivial debugging messages in the recovery process.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/node.c | 1 -
fs/f2fs/recovery.c | 44 +---
2 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b41482d..5a59780 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1495,7 +1495,6 @@ int recover_inode_page(struct f2fs_sb_info *sbi, struct
page *page)
WARN_ON(1);
set_node_addr(sbi, _ni, NEW_ADDR);
inc_valid_inode_count(sbi);
-
f2fs_put_page(ipage, 1);
return 0;
}
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index c573944..774efdb 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -49,9 +49,6 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
struct inode *dir;
int err = 0;
- if (!is_dent_dnode(ipage))
- goto out;
-
dir = check_dirty_dir_inode(F2FS_SB(inode->i_sb), pino);
if (!dir) {
dir = f2fs_iget(inode->i_sb, pino);
@@ -73,6 +70,9 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
err = __f2fs_add_link(dir, , inode);
}
out:
+ f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode and its dentry: "
+ "ino = %x, name = %s, dir = %lx, err = %d",
+ ino_of_node(ipage), raw_inode->i_name, dir->i_ino, err);
kunmap(ipage);
return err;
}
@@ -83,6 +83,9 @@ static int recover_inode(struct inode *inode, struct page
*node_page)
struct f2fs_node *raw_node = (struct f2fs_node *)kaddr;
struct f2fs_inode *raw_inode = &(raw_node->i);
+ if (!IS_INODE(node_page))
+ return 0;
+
inode->i_mode = le16_to_cpu(raw_inode->i_mode);
i_size_write(inode, le64_to_cpu(raw_inode->i_size));
inode->i_atime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
@@ -92,7 +95,12 @@ static int recover_inode(struct inode *inode, struct page
*node_page)
inode->i_ctime.tv_nsec = le32_to_cpu(raw_inode->i_ctime_nsec);
inode->i_mtime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
- return recover_dentry(node_page, inode);
+ if (is_dent_dnode(node_page))
+ return recover_dentry(node_page, inode);
+
+ f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode: ino = %x, name = %s",
+ ino_of_node(node_page), raw_inode->i_name);
+ return 0;
}
static int find_fsync_dnodes(struct f2fs_sb_info *sbi, struct list_head *head)
@@ -123,7 +131,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
lock_page(page);
if (cp_ver != cpver_of_node(page))
- goto unlock_out;
+ break;
if (!is_fsync_dnode(page))
goto next;
@@ -133,40 +141,33 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
if (IS_INODE(page) && is_dent_dnode(page)) {
err = recover_inode_page(sbi, page);
if (err)
- goto unlock_out;
+ break;
}
/* add this fsync inode to the list */
entry = kmem_cache_alloc(fsync_entry_slab, GFP_NOFS);
if (!entry) {
err = -ENOMEM;
- goto unlock_out;
+ break;
}
entry->inode = f2fs_iget(sbi->sb, ino_of_node(page));
if (IS_ERR(entry->inode)) {
err = PTR_ERR(entry->inode);
kmem_cache_free(fsync_entry_slab, entry);
- goto unlock_out;
+ break;
}
list_add_tail(>list, head);
}
entry->blkaddr = blkaddr;
- if (IS_INODE(page)) {
- err = recover_inode(entry->inode, page);
- if (err == -ENOENT) {
- goto next;
- } else if (err) {
- err = -EINVAL;
- goto unlock_out;
- }
- }
+ err = recover_inode(entry->inode, page);
+ if (err && err != -ENOENT)
+ break;
next:
/* check next segment */
blkaddr = next_blkaddr_of_node(page);
}
-unlock_out:
unlock_page(page);
out:
__free_pages(page, 0);
@@ -244,7 +245,7 @@ static int do_recover_data(struct f2fs_sb_info *sbi, struct
inode *inode,
struct
Re: [PATCH] virtio-net: Reporting traffic queue distribution statistics through ethtool
On 05/20/2013 06:56 AM, Narasimhan, Sriram wrote:
> Hi Michael,
>
> Comments inline...
>
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Sunday, May 19, 2013 1:03 PM
> To: Narasimhan, Sriram
> Cc: ru...@rustcorp.com.au; virtualizat...@lists.linux-foundation.org;
> k...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Jason Wang
> Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution
> statistics through ethtool
>
> On Sun, May 19, 2013 at 04:09:48PM +, Narasimhan, Sriram wrote:
>> Hi Michael,
>>
>> I was getting all packets on the same inbound queue which
>> is why I added this support to virtio-net (and some more
>> instrumentation at tun as well). But, it turned out to be
>> my misconfiguration - I did not enable IFF_MULTI_QUEUE on
>> the tap device, so the real_num_tx_queues on tap netdev was
>> always 1 (no tx distribution at tap).
> Interesting that qemu didn't fail.
>
> [Sriram] void tun_set_real_num_tx_queues() does not return
> the EINVAL return from netif_set_real_num_tx_queues() for
> txq > dev->num_tx_queues (which would be the case if the
> tap device were not created with IFF_MULTI_QUEUE). I think
> it would be better to fix the code to disable the new
> queue and fail tun_attach() in this scenario. If you
> agree, I can go ahead and create a separate patch for that.
>
But tun_attach() check the TUN_TAP_MQ flags before, so it should fail?
How was the tap created?
>> I am thinking about
>> adding a -q option to tunctl to specify multi-queue flag on
>> the tap device.
> Absolutely.
>
> [Sriram] OK, let me do that.
>
>> Yes, number of exits will be most useful. I will look into
>> adding the other statistics you mention.
>>
>> Sriram
> Pls note you'll need to switch to virtqueue_kick_prepare
> to detect exits: virtqueue_kick doesn't let you know
> whether there was an exit.
>
> Also, it's best to make this a separate patch from the one
> adding per-queue stats.
>
> [Sriram] OK, I will cover only the per-queue statistics in
> this patch. Also, I will address the indentation/data
> structure name points that you mentioned in your earlier
> email and send a new revision for this patch.
>
> Sriram
Better have some performance numbers to make sure nothing was slowed down.
Thanks
>
>> -Original Message-
>> From: Michael S. Tsirkin [mailto:m...@redhat.com]
>> Sent: Sunday, May 19, 2013 4:28 AM
>> To: Narasimhan, Sriram
>> Cc: ru...@rustcorp.com.au; virtualizat...@lists.linux-foundation.org;
>> k...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution
>> statistics through ethtool
>>
>> On Thu, May 16, 2013 at 01:24:29PM -0700, Sriram Narasimhan wrote:
>>> This patch allows virtio-net driver to report traffic distribution
>>> to inbound/outbound queues through ethtool -S. The per_cpu
>>> virtnet_stats is split into receive and transmit stats and are
>>> maintained on a per receive_queue and send_queue basis.
>>> virtnet_stats() is modified to aggregate interface level statistics
>>> from per-queue statistics. Sample output below:
>>>
>> Thanks for the patch. The idea itself looks OK to me.
>> Ben Hutchings already sent some comments
>> so I won't repeat them. Some minor more comments
>> and questions below.
>>
>>> NIC statistics:
>>> rxq0: rx_packets: 4357802
>>> rxq0: rx_bytes: 292642052
>>> txq0: tx_packets: 824540
>>> txq0: tx_bytes: 55256404
>>> rxq1: rx_packets: 0
>>> rxq1: rx_bytes: 0
>>> txq1: tx_packets: 1094268
>>> txq1: tx_bytes: 73328316
>>> rxq2: rx_packets: 0
>>> rxq2: rx_bytes: 0
>>> txq2: tx_packets: 1091466
>>> txq2: tx_bytes: 73140566
>>> rxq3: rx_packets: 0
>>> rxq3: rx_bytes: 0
>>> txq3: tx_packets: 1093043
>>> txq3: tx_bytes: 73246142
>> Interesting. This example implies that all packets are coming in
>> through the same RX queue - is this right?
>> If yes that's worth exploring - could be a tun bug -
>> and shows how this patch is useful.
>>
>>> Signed-off-by: Sriram Narasimhan
>> BTW, while you are looking at the stats, one other interesting
>> thing to add could be checking more types of stats: number of exits,
>> queue full errors, etc.
>>
>>> ---
>>> drivers/net/virtio_net.c | 157
>>> +-
>>> 1 files changed, 128 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>> index 3c23fdc..3c58c52 100644
>>> --- a/drivers/net/virtio_net.c
>>> +++ b/drivers/net/virtio_net.c
>>> @@ -41,15 +41,46 @@ module_param(gso, bool, 0444);
>>>
>>> #define VIRTNET_DRIVER_VERSION "1.0.0"
>>>
>>> -struct virtnet_stats {
>>> - struct u64_stats_sync tx_syncp;
>>> +struct virtnet_rx_stats {
>>> struct u64_stats_sync rx_syncp;
>>> - u64 tx_bytes;
>>> + u64 rx_packets;
>>> + u64 rx_bytes;
>>> +};
>>> +
RE: [PATCH v3] clocksource: add MVF600 pit timer support
>-Original Message- >From: Shawn Guo [mailto:shawn@linaro.org] >Sent: Monday, May 20, 2013 11:21 AM >To: Lu Jingchang-B35083 >Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; >john.stu...@linaro.org; t...@linutronix.de; s.ha...@pengutronix.de >Subject: Re: [PATCH v3] clocksource: add MVF600 pit timer support > >On Mon, May 20, 2013 at 03:08:54AM +, Lu Jingchang-B35083 wrote: >> [Lu Jingchang-B35083] >> I am not sure MVF5xx and MVF7xx have the same PIT block, if you have >information that it is the same on other Vybrid SoCs, it is ok to change >the driver name to mvf. Thanks! > >Even the PIT block on other Vybrid SoCs have differences from the one >integrated on mvf600, we can handle them using device tree compatible >string. And that's why we need to encode SoC name in compatible. > [Lu Jingchang-B35083] Ok, I will rename the driver and the configure option, thanks! >> [Lu Jingchang-B35083] >> PIT0 and PIT1 can be chained to build a 64-bit timer, so PIT2 and PIT3 >are selected as the clocksource and clockevent device, and leave PIT0 and >PIT1 unused for anyone else who needs them. Thanks! > >This could be an useful info to be in the comment. > [Lu Jingchang-B35083] I will add a comment for this, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] clocksource: add MVF600 pit timer support
On Mon, May 20, 2013 at 03:08:54AM +, Lu Jingchang-B35083 wrote: > [Lu Jingchang-B35083] > I am not sure MVF5xx and MVF7xx have the same PIT block, if you have > information that it is the same on other Vybrid SoCs, it is ok to change the > driver name to mvf. Thanks! Even the PIT block on other Vybrid SoCs have differences from the one integrated on mvf600, we can handle them using device tree compatible string. And that's why we need to encode SoC name in compatible. > [Lu Jingchang-B35083] > PIT0 and PIT1 can be chained to build a 64-bit timer, so PIT2 and PIT3 are > selected as the clocksource and clockevent device, and leave PIT0 and PIT1 > unused for anyone else who needs them. Thanks! This could be an useful info to be in the comment. 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/
[PATCH 1/2] f2fs: remove unnecessary kmap/kunmap operations
The allocated page used by the recovery is not on HIGHMEM, so that we don't
need to use kmap/kunmap.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 774efdb..5fcdd08 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -40,11 +40,11 @@ static struct fsync_inode_entry *get_fsync_inode(struct
list_head *head,
static int recover_dentry(struct page *ipage, struct inode *inode)
{
- struct f2fs_node *raw_node = (struct f2fs_node *)kmap(ipage);
+ void *kaddr = page_address(ipage);
+ struct f2fs_node *raw_node = (struct f2fs_node *)kaddr;
struct f2fs_inode *raw_inode = &(raw_node->i);
nid_t pino = le32_to_cpu(raw_inode->i_pino);
struct qstr name;
- struct f2fs_dir_entry *de;
struct page *page;
struct inode *dir;
int err = 0;
@@ -62,8 +62,7 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
name.len = le32_to_cpu(raw_inode->i_namelen);
name.name = raw_inode->i_name;
- de = f2fs_find_entry(dir, , );
- if (de) {
+ if (f2fs_find_entry(dir, , )) {
kunmap(page);
f2fs_put_page(page, 0);
} else {
@@ -73,7 +72,6 @@ out:
f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode and its dentry: "
"ino = %x, name = %s, dir = %lx, err = %d",
ino_of_node(ipage), raw_inode->i_name, dir->i_ino, err);
- kunmap(ipage);
return err;
}
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] f2fs: fix to unlock page before exit
If we got an error after lock_page, we should unlock it before exit.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 5fcdd08..edb89a3 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -343,7 +343,7 @@ static int recover_data(struct f2fs_sb_info *sbi,
lock_page(page);
if (cp_ver != cpver_of_node(page))
- goto unlock_out;
+ break;
entry = get_fsync_inode(head, ino_of_node(page));
if (!entry)
@@ -351,7 +351,7 @@ static int recover_data(struct f2fs_sb_info *sbi,
err = do_recover_data(sbi, entry->inode, page, blkaddr);
if (err)
- goto out;
+ break;
if (entry->blkaddr == blkaddr) {
iput(entry->inode);
@@ -362,7 +362,6 @@ next:
/* check next segment */
blkaddr = next_blkaddr_of_node(page);
}
-unlock_out:
unlock_page(page);
out:
__free_pages(page, 0);
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2
Hi, Borislav
On 05/17/2013 09:56 PM, Borislav Petkov wrote:
[snip]
> [ 51.737378] [] native_smp_send_reschedule+0x58/0x60
> [ 51.744013] [] wake_up_nohz_cpu+0x2d/0xa0
I suppose the reason is that the cpu we passed to mod_delayed_work_on()
has a chance to become offline before we disabled irq, what about check
it before send resched ipi? like:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index bfa7e77..d0e8f15 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -626,7 +626,7 @@ static bool wake_up_full_nohz_cpu(int cpu)
void wake_up_nohz_cpu(int cpu)
{
- if (!wake_up_full_nohz_cpu(cpu))
+ if (cpu_online(cpu) && !wake_up_full_nohz_cpu(cpu))
wake_up_idle_cpu(cpu);
}
Regards,
Michael Wang
> [ 51.749745] [] add_timer_on+0x8f/0x110
> [ 51.755214] [] __queue_delayed_work+0x16e/0x1a0
> [ 51.761470] [] ? try_to_grab_pending+0xd1/0x1a0
> [ 51.767724] [] mod_delayed_work_on+0x5a/0xa0
> [ 51.773719] [] gov_queue_work+0x4d/0xc0
> [ 51.779271] [] od_dbs_timer+0xcb/0x170
> [ 51.784734] [] process_one_work+0x1fd/0x540
> [ 51.790634] [] ? process_one_work+0x192/0x540
> [ 51.796711] [] worker_thread+0x122/0x380
> [ 51.802350] [] ? rescuer_thread+0x320/0x320
> [ 51.808264] [] kthread+0xea/0xf0
> [ 51.813200] [] ? flush_kthread_worker+0x150/0x150
> [ 51.819644] [] ret_from_fork+0x7c/0xb0
> [ 51.918165] nouveau E[ DRM] GPU lockup - switching to software fbcon
> [ 51.930505] [] ? flush_kthread_worker+0x150/0x150
> [ 51.936994] ---[ end trace f419538ada83b5c5 ]---
> [ 51.942915] [ cut here ]
> [ 51.942928] [ cut here ]
> [ 51.942936] WARNING: at arch/x86/kernel/smp.c:123
> native_smp_send_reschedule+0x58/0x60()
> [ 51.942974] Modules linked in: ext2 vfat fat loop snd_hda_codec_hdmi
> usbhid snd_hda_codec_realtek coretemp kvm_intel kvm snd_hda_intel
> snd_hda_codec crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hwdep snd_pcm
> aesni_intel sb_edac aes_x86_64 ehci_pci snd_page_alloc glue_helper snd_timer
> xhci_hcd snd iTCO_wdt iTCO_vendor_support ehci_hcd edac_core lpc_ich
> acpi_cpufreq lrw gf128mul ablk_helper cryptd mperf usbcore usb_common
> soundcore mfd_core dcdbas evdev pcspkr processor i2c_i801 button microcode
> [ 51.942978] CPU: 5 PID: 740 Comm: kworker/3:2 Tainted: GW
> 3.10.0-rc1+ #10
> [ 51.942979] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08
> 01/24/2013
> [ 51.942985] Workqueue: events od_dbs_timer
> [ 51.942990] 0009 88043ab0db68 8161441c
> 88043ab0dba8
> [ 51.942994] 8103e540 3ab0dbf8 0003
> 88043d708000
> [ 51.942998] 0d32 0003 88044fccfc08
> 88043ab0dbb8
> [ 51.942999] Call Trace:
> [ 51.943005] [] dump_stack+0x19/0x1b
> [ 51.943010] [] warn_slowpath_common+0x70/0xa0
> [ 51.943014] [] warn_slowpath_null+0x1a/0x20
> [ 51.943017] [] native_smp_send_reschedule+0x58/0x60
> [ 51.943021] [] wake_up_nohz_cpu+0x2d/0xa0
> [ 51.943027] [] add_timer_on+0x8f/0x110
> [ 51.943031] [] __queue_delayed_work+0x16e/0x1a0
> [ 51.943035] [] ? try_to_grab_pending+0xd1/0x1a0
> [ 51.943038] [] mod_delayed_work_on+0x5a/0xa0
> [ 51.943043] [] gov_queue_work+0x4d/0xc0
> [ 51.943046] [] od_dbs_timer+0xcb/0x170
> [ 51.943050] [] process_one_work+0x1fd/0x540
> [ 51.943053] [] ? process_one_work+0x192/0x540
> [ 51.943057] [] worker_thread+0x122/0x380
> [ 51.943060] [] ? rescuer_thread+0x320/0x320
> [ 51.943063] [] kthread+0xea/0xf0
> [ 51.943068] [] ? flush_kthread_worker+0x150/0x150
> [ 51.943071] [] ret_from_fork+0x7c/0xb0
> [ 51.943074] [] ? flush_kthread_worker+0x150/0x150
> [ 51.943076] ---[ end trace f419538ada83b5c6 ]---
> [ 52.178461] WARNING: at arch/x86/kernel/smp.c:123
> native_smp_send_reschedule+0x58/0x60()
> [ 52.188097] Modules linked in: ext2 vfat fat loop snd_hda_codec_hdmi
> usbhid snd_hda_codec_realtek coretemp kvm_intel kvm snd_hda_intel
> snd_hda_codec crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hwdep snd_pcm
> aesni_intel sb_edac aes_x86_64 ehci_pci snd_page_alloc glue_helper snd_timer
> xhci_hcd snd iTCO_wdt iTCO_vendor_support ehci_hcd edac_core lpc_ich
> acpi_cpufreq lrw gf128mul ablk_helper cryptd mperf usbcore usb_common
> soundcore mfd_core dcdbas evdev pcspkr processor i2c_i801 button microcode
> [ 52.238477] CPU: 0 PID: 85 Comm: kworker/2:1 Tainted: GW
> 3.10.0-rc1+ #10
> [ 52.247669] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08
> 01/24/2013
> [ 52.256604] Workqueue: events od_dbs_timer
> [ 52.262219] 0009 88043b62db68 8161441c
> 88043b62dba8
> [ 52.271194] 8103e540 0033 0002
> 88043d6dc000
> [ 52.280163] 0d32 0002 88044fc8fc08
> 88043b62dbb8
> [ 52.289141] Call Trace:
> [ 52.293066]
RE: [PATCH v3] clocksource: add MVF600 pit timer support
>-Original Message- >From: Shawn Guo [mailto:shawn@linaro.org] >Sent: Monday, May 20, 2013 10:28 AM >To: Lu Jingchang-B35083 >Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; >john.stu...@linaro.org; t...@linutronix.de; s.ha...@pengutronix.de >Subject: Re: [PATCH v3] clocksource: add MVF600 pit timer support > >On Thu, May 16, 2013 at 02:15:24PM +0800, Jingchang Lu wrote: >> Add Freescale Vybrid MVF600 period interrupt timer support. >> >> Signed-off-by: Jingchang Lu >> --- >> v3: >> move the pit driver to drivers/clocksource. >> >> drivers/clocksource/Kconfig| 5 + >> drivers/clocksource/Makefile | 1 + >> drivers/clocksource/mvf600_pit_timer.c | 224 >> + > >This is a driver for PIT, a timer IP block found on mvf family. Even >though we prefer to use particular SoC name to specify the compatibility >and version of the block, all the versions of the IP block should be >ideally supported by single PIT driver. This is just like we have drivers >spi-imx and i2c-imx support all SPI and I2C controllers found on IMX SoCs. >That said, I suggest you use family name "mvf" to name the driver, Kconfig >symbol etc. and use "mvf600" only in compatible string. > [Lu Jingchang-B35083] I am not sure MVF5xx and MVF7xx have the same PIT block, if you have information that it is the same on other Vybrid SoCs, it is ok to change the driver name to mvf. Thanks! >> 3 files changed, 230 insertions(+) >> + >> +/* choose PIT2 as clocksource, PIT3 as clockevent dev */ > >Reading the comment, I have a natural question - what PIT0 and PIT1 are >used for? > [Lu Jingchang-B35083] PIT0 and PIT1 can be chained to build a 64-bit timer, so PIT2 and PIT3 are selected as the clocksource and clockevent device, and leave PIT0 and PIT1 unused for anyone else who needs 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/
Re: linux-next: build failure after merge of the rr-fixes tree
Stephen Rothwell writes:
> Hi Rusty,
>
> After merging the rr-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/dma/iovlock.c: In function 'dma_pin_iovec_pages':
> drivers/dma/iovlock.c:98:21: error: dereferencing pointer to incomplete type
>down_read(>mm->mmap_sem);
> ^
> drivers/dma/iovlock.c:101:11: error: dereferencing pointer to incomplete type
> current->mm,
>^
> drivers/dma/iovlock.c:108:19: error: dereferencing pointer to incomplete type
>up_read(>mm->mmap_sem);
>^
>
> Caused by commit 11227d242a8c ("Hoist memcpy_fromiovec/memcpy_toiovec
> into lib/"). Clearly, net/tcp.h was indirectly including sched.h or
> asm/current.h. Changing inclusions is fraught with problems since people
> do not follow Rule 1 (in Documentation/SubmitChecklist) consistently. :-(
Yep, the 0day tester caught this too (it works on 32-bit unfortunately,
so I didn't see the problem).
I've not touched the #includes any more in my updated patch.
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/
NIST SP800-138 availibility using kernel crypto APIs for SMB3.0 MAC generation
With the recent patches added to kernel crypto for improving AES support, adding aesni etc, it seems like it is time to add AES CMAC to the cifs kernel module (for the popular SMB3 signing and per-share encryption) but needed for an implementation for SP800-138 in kernel crypto codebase. Was specifically interested using the way defined in 3.1.4.2 of MS-SMB2 document, in particular KDF in Counter mode (section 5.1 of NIST SP 800-108) or a way to specify a mode PRF as HMAC-SHA256 (or a way to specify a PRF) cifs client would use this algorithm for SMB3.0 MAC generation (network packet signing on network file system mounts to newer generation NAS, and Windows 2012) and also for per-share encryption (which is also available on the most recent generation of NAS via SMB3). Apparently with current Intel processors having hardware for this kind of encryption offload - full packet encryption is faster than packet signing used to be (with the older standard algorithms) and just doing packet signing is really fast. Are their APIs in crypto kernel code to use for this purpose? Regards, Shirish -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On 05/20/2013 10:20 AM, Greg Kroah-Hartman wrote: > On Mon, May 20, 2013 at 10:12:41AM +0800, Chen Gang wrote: >> > I mean that if no reply by any other members within a week, I will know >> > it is correct that "we need not call device_remove_file() firstly before >> > call device_unregister()" (at least, one member's reply supports this >> > conclusion). >> > >> > I find this 'question' when discussing a patch with another members in >> > linux-kernel@vger.kernel.org, I have read the related code and also have >> > searched with google, but can not find the result, so I want to consult >> > it in linux-kernel@vger.kernel.org. > Asking random questions on lkml, and relying on the fact that no one > else happens to say anything, is not any judge as to if the answer is > correct at all. > OK, I can understand, now, thank you for your reply. And I wish, we can provide the confirmation of all related questions about Linux kernel, in the future, > In fact, just asking questions on lkml has a very low chance of ever > getting a correct answer, given that the people that usually do know the > answer to these types of things are usually: > 1) not reading lkml because they are busy doing real work I should understand, they have no duty to have to reply the related mail, especially every members already have their own work (and normally, they are really busy). > 2) annoyed by questions that are easily answered by themselves by > either: >a) reading the code I have done, so I need not worry about this item. :-) >b) writing a simple example module and testing it out yourself > Precisely, I did not do it firstly. It seems I should do it firstly (although, at least now, I do not think it will get any valuable result for our this case) > > Good luck, > OK, 'Lucky' is really the first important !! I should continue to analyze this question, independent this 'consult' mail. Thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv2] virtio_pci: better macro exported in uapi
"Michael S. Tsirkin" writes: > Macro VIRTIO_PCI_CONFIG assumes that userspace actually has a structure > with a field named msix_enabled. Add VIRTIO_PCI_CONFIG_OFF that gets > the msix_enabled by value instead, to make it useful for userspace. We > still keep VIRTIO_PCI_CONFIG around for now, in case some userspace uses > it. > > Signed-off-by: Michael S. Tsirkin Applied. Thanks, Rusty. > --- > > Changes from v1: > - rename macro to VIRTIO_PCI_CONFIG_OFF so preprocessor > can be used to check for its presence, as suggested > by Rusty > - keep old macro around as suggested by David Howells > > include/uapi/linux/virtio_pci.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h > index ea66f3f..e5ec1ca 100644 > --- a/include/uapi/linux/virtio_pci.h > +++ b/include/uapi/linux/virtio_pci.h > @@ -80,7 +80,9 @@ > > /* The remaining space is defined by each driver as the per-driver > * configuration space */ > -#define VIRTIO_PCI_CONFIG(dev) ((dev)->msix_enabled ? 24 : 20) > +#define VIRTIO_PCI_CONFIG_OFF(msix_enabled) ((msix_enabled) ? 24 : 20) > +/* Deprecated: please use VIRTIO_PCI_CONFIG_OFF instead */ > +#define VIRTIO_PCI_CONFIG(dev) > VIRTIO_PCI_CONFIG_OFF((dev)->msix_enabled) > > /* Virtio ABI version, this must match exactly */ > #define VIRTIO_PCI_ABI_VERSION 0 > -- > MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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_pci: fix macro exported in uapi
David Howells writes: > Rusty Russell wrote: > >> Macro still isn't usable, because userspace can't know whether it's the >> new or old. >> >> We need to either remove it from UAPI, or rename it to >> VIRTIO_PCI_CONFIG_OFF. > > Surely, if userspace is using it as is, you can't remove it, rename it or > alter it? The point of the patch is that it's unusable: #define VIRTIO_PCI_CONFIG(dev) ((dev)->msix_enabled ? 24 : 20) ie. it's accessing a member of the kernel's virtio_pci_dev structure. In theory, userspace could have a structure with the same field and be using it now, but that's unlikely (qemu certainly doesn't). No harm no foul. In theory it's actually a useful macro, so we could expose it to userspace, but we'd need to have a new name so userspace can #ifdef for older headers... Hope that clarifies, 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 v7 0/21] sched: power aware scheduling
Hi Alex, On 05/20/2013 06:31 AM, Alex Shi wrote: > >> Which are the workloads where 'powersaving' mode hurts workload >> performance measurably? >> >> I ran ebizzy on a 2 socket, 16 core, SMT 4 Power machine. > > Is this a 2 * 16 * 4 LCPUs PowerPC machine? This is a 2 * 8 * 4 LCPUs PowerPC machine. >> The power efficiency drops significantly with the powersaving policy of >> this patch,over the power efficiency of the scheduler without this patch. >> >> The below parameters are measured relative to the default scheduler >> behaviour. >> >> A: Drop in power efficiency with the patch+powersaving policy >> B: Drop in performance with the patch+powersaving policy >> C: Decrease in power consumption with the patch+powersaving policy >> >> NumThreads AB C >> - >> 2 33% 36% 4% >> 4 31% 33% 3% >> 8 28% 30% 3% >> 16 31% 33% 4% >> >> Each of the above run is for 30s. >> >> On investigating socket utilization,I found that only 1 socket was being >> used during all the above threaded runs. As can be guessed this is due >> to the group_weight being considered for the threshold metric. >> This stacks up tasks on a core and further on a socket, thus throttling >> them, as observed by Mike below. >> >> I therefore think we must switch to group_capacity as the metric for >> threshold and use only (rq->utils*nr_running) for group_utils >> calculation during non-bursty wakeup scenarios. >> This way we are comparing right; the utilization of the runqueue by the >> fair tasks and the cpu capacity available for them after being consumed >> by the rt tasks. >> >> After I made the above modification,all the above three parameters came >> to be nearly null. However, I am observing the load balancing of the >> scheduler with the patch and powersavings policy enabled. It is behaving >> very close to the default scheduler (spreading tasks across sockets). >> That also explains why there is no performance drop or gain with the >> patch+powersavings policy enabled. I will look into this observation and >> revert. > > Thanks a lot for the great testings! > Seem tasks per SMT cpu isn't power efficient. > And I got the similar result last week. I tested the fspin testing(do > endless calculation, in linux-next tree.). when I bind task per SMT cpu, > the power efficiency really dropped with most every threads number. but > when bind task per core, it has better power efficiency on all threads. > Beside to move task depend on group_capacity, another choice is balance > task according cpu_power. I did the transfer in code. but need to go > through a internal open source process before public them. What do you mean by *another* choice is balance task according to cpu_power? group_capacity is based on cpu_power. Also, your balance policy in v6 was doing the same right? It was rightly comparing rq->utils * nr_running against cpu_power. Why not simply switch to that code for power policy load balancing? > Well, it'll lose throughput any time there's parallel execution > potential but it's serialized instead.. using average will inevitably > stack tasks sometimes, but that's its goal. Hackbench shows it. (but that consolidation can be a winner too, and I bet a nickle it would be for a socket sized pgbench run) >>> >>> (belay that, was thinking of keeping all tasks on a single node, but >>> it'll likely stack the whole thing on a CPU or two, if so, it'll hurt) >> >> At this point, I would like to raise one issue. >> *Is the goal of the power aware scheduler improving power efficiency of >> the scheduler or a compromise on the power efficiency but definitely a >> decrease in power consumption, since it is the user who has decided to >> prioritise lower power consumption over performance* ? >> > > It could be one of reason for this feather, but I could like to > make it has better efficiency, like packing tasks according to cpu_power > not current group_weight. Yes we could try the patch using group_capacity and observe the results for power efficiency, before we decide to compromise on power efficiency for decrease in power. Regards Preeti U Murthy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: asus-laptop: fix invalid point access
asus->name is null or point to const string,so it is not suitable to kfree it. Signed-off-by: Libo Chen --- drivers/platform/x86/asus-laptop.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c index 0eea09c..8e268da 100644 --- a/drivers/platform/x86/asus-laptop.c +++ b/drivers/platform/x86/asus-laptop.c @@ -1935,7 +1935,6 @@ fail_input: fail_backlight: asus_platform_exit(asus); fail_platform: - kfree(asus->name); kfree(asus); return result; -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] x86 platform drivers: fix gpio leak
when request_irq faild, we should release gpiochip
Signed-off-by: Libo Chen
---
drivers/platform/x86/intel_pmic_gpio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
mode change 100644 => 100755 drivers/platform/x86/intel_pmic_gpio.c
diff --git a/drivers/platform/x86/intel_pmic_gpio.c
b/drivers/platform/x86/intel_pmic_gpio.c
old mode 100644
new mode 100755
index 6f4b728..478c3a5
--- a/drivers/platform/x86/intel_pmic_gpio.c
+++ b/drivers/platform/x86/intel_pmic_gpio.c
@@ -288,7 +288,7 @@ static int platform_pmic_gpio_probe(struct platform_device
*pdev)
retval = request_irq(pg->irq, pmic_irq_handler, 0, "pmic", pg);
if (retval) {
pr_warn("Interrupt request failed\n");
- goto err;
+ goto fail_request_irq;
}
for (i = 0; i < 8; i++) {
@@ -299,6 +299,9 @@ static int platform_pmic_gpio_probe(struct platform_device
*pdev)
irq_set_chip_data(i + pg->irq_base, pg);
}
return 0;
+
+fail_request_irq:
+ gpiochip_remove(>chip);
err:
iounmap(pg->gpiointr);
err2:
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] fix x86 driver memleak
fix memleak or invalite point acesss about x86 platform drivers Libo Chen (3): x86: msi-laptop: fix memleak x86: asus-laptop: fix invalid point access x86 platform drivers: fix gpio leak drivers/platform/x86/asus-laptop.c | 1 - drivers/platform/x86/intel_pmic_gpio.c | 5 - drivers/platform/x86/msi-laptop.c | 24 ++-- 3 files changed, 14 insertions(+), 16 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] x86: msi-laptop: fix memleak
1. fix two visible mistakes:
* when load_scm_model_init faild, we should call
platform_device_del(msipf_device)
* msipf_attribute_group should be remove in err case
2. change some tags, give them real meaning.
Signed-off-by: Libo Chen
---
drivers/platform/x86/msi-laptop.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
mode change 100644 => 100755 drivers/platform/x86/msi-laptop.c
diff --git a/drivers/platform/x86/msi-laptop.c
b/drivers/platform/x86/msi-laptop.c
old mode 100644
new mode 100755
index 6b22938..62f8030
--- a/drivers/platform/x86/msi-laptop.c
+++ b/drivers/platform/x86/msi-laptop.c
@@ -1098,29 +1098,29 @@ static int __init msi_init(void)
ret = platform_device_add(msipf_device);
if (ret)
- goto fail_platform_device1;
+ goto fail_device_add;
if (quirks->load_scm_model && (load_scm_model_init(msipf_device) < 0)) {
ret = -EINVAL;
- goto fail_platform_device1;
+ goto fail_scm_model_init;
}
ret = sysfs_create_group(_device->dev.kobj,
_attribute_group);
if (ret)
- goto fail_platform_device2;
+ goto fail_create_group;
if (!quirks->old_ec_model) {
if (threeg_exists)
ret = device_create_file(_device->dev,
_attr_threeg);
if (ret)
- goto fail_platform_device2;
+ goto fail_create_attr;
} else {
ret = sysfs_create_group(_device->dev.kobj,
_old_attribute_group);
if (ret)
- goto fail_platform_device2;
+ goto fail_create_attr;
/* Disable automatic brightness control by default because
* this module was probably loaded to do brightness control in
@@ -1134,26 +1134,22 @@ static int __init msi_init(void)
return 0;
-fail_platform_device2:
-
+fail_create_attr:
+ sysfs_remove_group(_device->dev.kobj, _attribute_group);
+fail_create_group:
if (quirks->load_scm_model) {
i8042_remove_filter(msi_laptop_i8042_filter);
cancel_delayed_work_sync(_rfkill_dwork);
cancel_work_sync(_rfkill_work);
rfkill_cleanup();
}
+fail_scm_model_init:
platform_device_del(msipf_device);
-
-fail_platform_device1:
-
+fail_device_add:
platform_device_put(msipf_device);
-
fail_platform_driver:
-
platform_driver_unregister(_driver);
-
fail_backlight:
-
backlight_device_unregister(msibl_device);
return ret;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] clocksource: add MVF600 pit timer support
On Thu, May 16, 2013 at 02:15:24PM +0800, Jingchang Lu wrote:
> Add Freescale Vybrid MVF600 period interrupt timer support.
>
> Signed-off-by: Jingchang Lu
> ---
> v3:
> move the pit driver to drivers/clocksource.
>
> drivers/clocksource/Kconfig| 5 +
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/mvf600_pit_timer.c | 224
> +
This is a driver for PIT, a timer IP block found on mvf family. Even
though we prefer to use particular SoC name to specify the compatibility
and version of the block, all the versions of the IP block should be
ideally supported by single PIT driver. This is just like we have
drivers spi-imx and i2c-imx support all SPI and I2C controllers found on
IMX SoCs.
That said, I suggest you use family name "mvf" to name the driver,
Kconfig symbol etc. and use "mvf600" only in compatible string.
> 3 files changed, 230 insertions(+)
> create mode 100644 drivers/clocksource/mvf600_pit_timer.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index f151c6c..2808a76 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -85,3 +85,8 @@ config CLKSRC_SAMSUNG_PWM
> Samsung S3C, S5P and Exynos SoCs, replacing an earlier driver
> for all devicetree enabled platforms. This driver will be
> needed only on systems that do not have the Exynos MCT available.
> +
> +config MVF600_PIT_TIMER
> + bool
> + help
> + Support for Period Interrupt Timer on Freescale Vybrid MVF600 SoC.
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 8d979c7..f471ca3 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_ARCH_BCM) += bcm_kona_timer.o
> obj-$(CONFIG_CADENCE_TTC_TIMER) += cadence_ttc_timer.o
> obj-$(CONFIG_CLKSRC_EXYNOS_MCT) += exynos_mct.o
> obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
> +obj-$(CONFIG_MVF600_PIT_TIMER) += mvf600_pit_timer.o
>
> obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
> obj-$(CONFIG_CLKSRC_METAG_GENERIC) += metag_generic.o
> diff --git a/drivers/clocksource/mvf600_pit_timer.c
> b/drivers/clocksource/mvf600_pit_timer.c
> new file mode 100644
> index 000..74f7963
> --- /dev/null
> +++ b/drivers/clocksource/mvf600_pit_timer.c
> @@ -0,0 +1,224 @@
> +/*
> + * Copyright 2012-2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * 8 timers: pit0 - pit7,
> + * Each takes 0x10 Bytes register sapce
s/sapce/space
> + */
> +#define PITMCR 0x00
> +#define PIT0_OFFSET 0x100
> +#define PITn_OFFSET(n) (PIT0_OFFSET + 0x10 * (n))
> +#define PITLDVAL 0x00
> +#define PITCVAL 0x04
> +#define PITTCTRL 0x08
> +#define PITTFLG 0x0c
> +
> +#define PITTCTRL_TEN (0x1 << 0)
> +#define PITTCTRL_TIE (0x1 << 1)
> +#define PITCTRL_CHN (0x1 << 2)
Use space than tab between "#define" and macro name.
> +
> +#define PITTFLG_TIF 0x1
> +
> +static struct clock_event_device clockevent_pit;
> +static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_UNUSED;
> +
> +static void __iomem *clksrc_base;
> +static void __iomem *clkevt_base;
> +static void __iomem *sched_clock_reg;
> +static unsigned long pit_cycle_per_jiffy;
> +
> +static inline void pit_timer_enable(void)
> +{
> + __raw_writel(PITTCTRL_TEN | PITTCTRL_TIE, clkevt_base + PITTCTRL);
> +}
> +
> +static inline void pit_timer_disable(void)
> +{
> + __raw_writel(0, clkevt_base + PITTCTRL);
> +}
> +
> +static inline void pit_irq_disable(void)
> +{
> + unsigned long val;
> +
> + val = __raw_readl(clkevt_base + PITTCTRL);
> + val &= ~PITTCTRL_TIE;
> + __raw_writel(val, clkevt_base + PITTCTRL);
> +}
> +
> +static inline void pit_irq_enable(void)
> +{
> + unsigned long val;
> +
> + val = __raw_readl(clkevt_base + PITTCTRL);
> + val |= PITTCTRL_TIE;
> + __raw_writel(val, clkevt_base + PITTCTRL);
> +}
> +
> +static void pit_irq_acknowledge(void)
> +{
> + __raw_writel(PITTFLG_TIF, clkevt_base + PITTFLG);
> +}
> +
> +static unsigned int pit_read_sched_clock(void)
> +{
> + return __raw_readl(sched_clock_reg);
> +}
> +
> +
> +static int __init pit_clocksource_init(struct clk *pit_clk)
> +{
> + unsigned int c = clk_get_rate(pit_clk);
> +
> + sched_clock_reg = clksrc_base + PITCVAL;
> +
> + setup_sched_clock(pit_read_sched_clock, 32, c);
> + return clocksource_mmio_init(clksrc_base + PITCVAL, "mvf600-pit", c,
> + 300, 32,
[PATCH v6 05/10 fix] mtd: get the ECC info from the Extended Parameter Page
Since the ONFI 2.1, the onfi spec adds the Extended Parameter Page
to store the ECC info.
The onfi spec tells us that if the nand chip's recommended ECC codeword
size is not 512 bytes, then the @ecc_bits is 0xff. The host _SHOULD_ then
read the Extended ECC information that is part of the extended parameter
page to retrieve the ECC requirements for this device.
This patch implement the reading of the Extended Parameter Page, and parses
the sections for ECC type, and get the ECC info from the ECC section.
Tested this patch with Micron MT29F64G08CBABAWP.
Acked-by: Pekon Gupta
Signed-off-by: Huang Shijie
---
drivers/mtd/nand/nand_base.c | 88 ++
1 files changed, 88 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index b63b731..3edf825 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2835,6 +2835,79 @@ static u16 onfi_crc16(u16 crc, u8 const *p, size_t len)
return crc;
}
+/* Parse the Extended Parameter Page. */
+static int nand_flash_detect_ext_param_page(struct mtd_info *mtd,
+ struct nand_chip *chip, struct nand_onfi_params *p)
+{
+ struct onfi_ext_param_page *ep;
+ struct onfi_ext_section *s;
+ struct onfi_ext_ecc_info *ecc;
+ uint8_t *cursor;
+ int ret = -EINVAL;
+ int len;
+ int i;
+
+ len = le16_to_cpu(p->ext_param_page_length) * 16;
+ ep = kmalloc(len, GFP_KERNEL);
+ if (!ep) {
+ ret = -ENOMEM;
+ goto ext_out;
+ }
+
+ /* Send our own NAND_CMD_PARAM. */
+ chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
+
+ /* Use the Change Read Column command to skip the ONFI param pages. */
+ chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
+ sizeof(*p) * p->num_of_param_pages , -1);
+
+ /* Read out the Extended Parameter Page. */
+ chip->read_buf(mtd, (uint8_t *)ep, len);
+ if ((onfi_crc16(ONFI_CRC_BASE, ((uint8_t *)ep) + 2, len - 2)
+ != le16_to_cpu(ep->crc))) {
+ pr_debug("fail in the CRC.\n");
+ goto ext_out;
+ }
+
+ /*
+* From section 5.7.2.2, we know that the Extened Param Page is valid
+* when two or more bytes of the signatrue are valid.
+* So we only check the first two bytes here.
+*/
+ if (strncmp(ep->sig, "EP", 2)) {
+ pr_debug("The signatrue is invalid.\n");
+ goto ext_out;
+ }
+
+ /* find the ECC section. */
+ cursor = (uint8_t *)(ep + 1);
+ for (i = 0; i < ONFI_EXT_SECTION_MAX; i++) {
+ s = ep->sections + i;
+ if (s->type == ONFI_SECTION_TYPE_2)
+ break;
+ cursor += s->length * 16;
+ }
+ if (i == ONFI_EXT_SECTION_MAX) {
+ pr_debug("We can not find the ECC section.\n");
+ goto ext_out;
+ }
+
+ /* get the info we want. */
+ ecc = (struct onfi_ext_ecc_info *)cursor;
+
+ if (ecc->codeword_size) {
+ chip->ecc_strength_ds = ecc->ecc_bits;
+ chip->ecc_step_ds = 1 << ecc->codeword_size;
+ }
+
+ pr_info("ONFI extended param page detected.\n");
+ return 0;
+
+ext_out:
+ kfree(ep);
+ return ret;
+}
+
/*
* Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
*/
@@ -2903,6 +2976,21 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd,
struct nand_chip *chip,
if (p->ecc_bits != 0xff) {
chip->ecc_strength_ds = p->ecc_bits;
chip->ecc_step_ds = 512;
+ } else if (chip->onfi_version >= 21 &&
+ (onfi_feature(chip) & ONFI_FEATURE_EXT_PARAM_PAGE)) {
+
+ /*
+* The nand_flash_detect_ext_param_page() uses the
+* Change Read Column command which maybe not supported
+* by the chip->cmdfunc. So try to update the chip->cmdfunc
+* now. We do not replace user supplied command function.
+*/
+ if (mtd->writesize > 512 && chip->cmdfunc == nand_command)
+ chip->cmdfunc = nand_command_lp;
+
+ /* The Extended Parameter Page is supported since ONFI 2.1. */
+ if (nand_flash_detect_ext_param_page(mtd, chip, p))
+ pr_info("Failed to detect the extended param page.\n");
}
pr_info("ONFI flash detected\n");
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On Mon, May 20, 2013 at 10:12:41AM +0800, Chen Gang wrote: > I mean that if no reply by any other members within a week, I will know > it is correct that "we need not call device_remove_file() firstly before > call device_unregister()" (at least, one member's reply supports this > conclusion). > > I find this 'question' when discussing a patch with another members in > linux-kernel@vger.kernel.org, I have read the related code and also have > searched with google, but can not find the result, so I want to consult > it in linux-kernel@vger.kernel.org. Asking random questions on lkml, and relying on the fact that no one else happens to say anything, is not any judge as to if the answer is correct at all. In fact, just asking questions on lkml has a very low chance of ever getting a correct answer, given that the people that usually do know the answer to these types of things are usually: 1) not reading lkml because they are busy doing real work 2) annoyed by questions that are easily answered by themselves by either: a) reading the code b) writing a simple example module and testing it out yourself Good luck, 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: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On 05/20/2013 09:45 AM, Greg Kroah-Hartman wrote: > On Mon, May 20, 2013 at 09:03:27AM +0800, Chen Gang wrote: >> > On 05/18/2013 07:06 PM, Ming Lei wrote: >>> > > Hi, >>> > > >>> > > On Fri, May 17, 2013 at 1:43 PM, Chen Gang >>> > > wrote: > >> Hello All: > >> > >> I searched 'arch/*' and 'drivers/*' sub-directory, all of them are > >> 'obey > >> this rule', even in device_unregister() itself, it also firstly calls > >> device_remove_file(), then call kobject_del(). > >> > >> But after read the related code (fs/sysfs/*, drivers/base/core.c), it > >> seems kobject_del() -> sysfs_remove_dir() which will release all > >> related > >> things (can instead of device_remove_file()). > >> > >> So in fact, we need not call device_remove_file() before call > >> device_unregister(), is it correct ? >>> > > >>> > > Looks it is correct but it is a bit implicit. >>> > > >> > >> > If really no other members reply within a week, we should treat your >> > opinion (or suggestion) as the final result conclusion within >> > linux-kernel@vger.kernel.org. :-) > I have no idea what you mean by this. > I mean that if no reply by any other members within a week, I will know it is correct that "we need not call device_remove_file() firstly before call device_unregister()" (at least, one member's reply supports this conclusion). I find this 'question' when discussing a patch with another members in linux-kernel@vger.kernel.org, I have read the related code and also have searched with google, but can not find the result, so I want to consult it in linux-kernel@vger.kernel.org. And I think, this 'question' is not suitable to give a test firstly, because the test plan need be discussed firstly (or the test result means nothing). This time, I send the 'consult' mail to 'All', not to specific members. Thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vhost-scsi: Depend on NET for memcpy_fromiovec
On Fri, May 17, 2013 at 04:25:49PM +0930, Rusty Russell wrote:
> Randy Dunlap writes:
> > On 05/16/13 16:42, Rusty Russell wrote:
> >> Joe Perches writes:
> >>> On Thu, 2013-05-16 at 13:04 +0930, Rusty Russell wrote:
> Asias He writes:
> > On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
> >>> []
> > Other users are using memcpy_fromiovec and friends outside net. It seems
> > a good idea to put it in a util library. e.g. crypto/algif_skcipher.c
> > which also depends on NET for it.
> >>>
> >>> []
> Subject: Hoist memcpy_fromiovec into lib/
> >>>
> >>> You'll need the "friends" memcpy_toiovec too.
> >>>
> >>> $ git grep -E \bmemcpy\w+iovec\w*"
> >>> crypto/algif_hash.c:err = memcpy_toiovec(msg->msg_iov, ctx->result,
> >>> len);
> >>> crypto/algif_skcipher.c:err =
> >>> memcpy_fromiovec(page_address(sg_page(sg)) +
> >>> crypto/algif_skcipher.c:err =
> >>> memcpy_fromiovec(page_address(sg_page(sg + i)),
> >>> drivers/dma/iovlock.c:#include /* for memcpy_toiovec */
> >>> drivers/dma/iovlock.c: return memcpy_toiovec(iov, kdata, len);
> >>> drivers/dma/iovlock.c: err = memcpy_toiovec(iov, vaddr + offset,
> >>> len);
> >>> drivers/isdn/mISDN/socket.c:if (memcpy_fromiovec(skb_put(skb, len),
> >>> msg->msg_iov, len)) {
> >>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
> >>> memcpy_fromiovec((u8 *)va + page_o
> >>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
> >>> memcpy_toiovec(iov, (u8 *)va + pag
> >>
> >> Fascinating. These all indirectly depend on NET, so there's no problem
> >> at the moment. But it is a bit weird...
> >>
> >> crypto/algif_hash.c: depends on CRYPTO_USER_API_HASH -> NET
> >> crypto/algif_skcipher.c: depends on CRYPTO_USER_API_SKCIPHER -> NET
> >> drivers/dma/iovlock.c: depends on NET_DMA -> NET
> >> drivers/isdn/mISDN/socket.c: depends on MISDN -> ISDN -> NET
> >> drivers/misc/vmw_vmci/vmci_queue_pair.c: depends on VMCI -> NET
> >>
> >> Patch welcome.
> >>
> >> Meanwhile, to avoid more bikeshedding I've put the patch I posted with
> >> all acks in my fixes branch. One cycle through linux-next, then
> >> straight to Linus.
> >>
> >
> > I agree with whoever suggested that more be moved into /lib.
> > E.g., drivers/misc/vmw_vmci/Kconfig uses "depends on NET" because the
> > code there uses both memcpy_toiovec() and memcpy_fromiovec().
> > See commit ID 6d4f0139d642c45411a47879325891ce2a7c164a.
>
> (CC's trimmed).
>
> You Acked that commit :(
>
> At a glance, the only way to drive the vmw_vmci device is through
> net/vmw_vsock/vmci_transport.c, so without NET it's useless? But let's
> keep it neat anyway. This was compiletested with CONFIG_VMCI,
> CONFIG_DMA_ENGINE and !CONFIG_NET.
>
> Thanks,
> Rusty.
>
> From: Rusty Russell
> Subject: [PATCH] Hoist memcpy_fromiovec/memcpy_toiovec into lib/
>
> ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!
>
> That function is only present with CONFIG_NET. Turns out that
> crypto/algif_skcipher.c also uses that outside net, but it actually
> needs sockets anyway.
>
> In addition, commit 6d4f0139d642c45411a47879325891ce2a7c164a added
> CONFIG_NET dependency to CONFIG_VMCI for memcpy_toiovec, so hoist
> that function and revert that commit too.
>
> socket.h already include uio.h, so no callers *need* updating,
> though I update the obvious ones.
>
> Reported-by: Randy Dunlap
> Acked-by: David S. Miller
> Acked-by: Michael S. Tsirkin
> Signed-off-by: Rusty Russell
Acked-by: Asias He
> diff --git a/drivers/dma/iovlock.c b/drivers/dma/iovlock.c
> index bb48a57..6943deb66 100644
> --- a/drivers/dma/iovlock.c
> +++ b/drivers/dma/iovlock.c
> @@ -28,7 +28,7 @@
> #include
> #include
> #include
> -#include /* for memcpy_toiovec */
> +#include /* for memcpy_toiovec */
> #include
> #include
>
> diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig
> index ea98f7e..39c2eca 100644
> --- a/drivers/misc/vmw_vmci/Kconfig
> +++ b/drivers/misc/vmw_vmci/Kconfig
> @@ -4,7 +4,7 @@
>
> config VMWARE_VMCI
> tristate "VMware VMCI Driver"
> - depends on X86 && PCI && NET
> + depends on X86 && PCI
> help
> This is VMware's Virtual Machine Communication Interface. It enables
> high-speed communication between host and guest in a virtual
> diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
> b/drivers/misc/vmw_vmci/vmci_queue_pair.c
> index d94245d..8ff2e5e 100644
> --- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
> +++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
> @@ -23,7 +23,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 428c37a..33bf2df 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -305,7 +305,6 @@ struct ucred {
>
> extern void
RE: [PATCH 3.9-stable] NTB: variable dereferenced before check
Jon Mason agrees that this could also be applied to the 3.9
"Yes, please do. I'll respond to each of the patch series, but please apply
them all. Also, one patch was omitted from these, titled
NTB: variable dereferenced before check
Please include that patch in 3.9 stable as well.
"
Thanks.
Best Regards.
> -Original Message-
> From: stable-ow...@vger.kernel.org [mailto:stable-ow...@vger.kernel.org]
> On Behalf Of Jonghwan Choi
> Sent: Monday, May 20, 2013 10:58 AM
> To: 'Jonghwan Choi'; linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org; 'Jon Mason'; c...@samsung.com
> Subject: [PATCH 3.9-stable] NTB: variable dereferenced before check
>
> This patch looks like it should be in the 3.9-stable tree, should we apply
> it?
>
> --
>
> From: "Jon Mason "
>
> commit 186f27ff9f9ec5c110739ced88ce9f8fca053882 upstream
>
> Correct instances of variable dereferencing before checking its value on
> the functions exported to the client drivers. Also, add sanity checks
> for all exported functions.
>
> Reported-by: Dan Carpenter
> Signed-off-by: Jon Mason
> Signed-off-by: Jonghwan Choi
> ---
> drivers/ntb/ntb_transport.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> index e0bdfd7..74c5812 100644
> --- a/drivers/ntb/ntb_transport.c
> +++ b/drivers/ntb/ntb_transport.c
> @@ -1210,12 +1210,14 @@ EXPORT_SYMBOL_GPL(ntb_transport_create_queue);
> */
> void ntb_transport_free_queue(struct ntb_transport_qp *qp)
> {
> - struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
> + struct pci_dev *pdev;
> struct ntb_queue_entry *entry;
>
> if (!qp)
> return;
>
> + pdev = ntb_query_pdev(qp->ndev);
> +
> cancel_delayed_work_sync(>link_work);
>
> ntb_unregister_db_callback(qp->ndev, qp->qp_num);
> @@ -1371,12 +1373,13 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_up);
> */
> void ntb_transport_link_down(struct ntb_transport_qp *qp)
> {
> - struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
> + struct pci_dev *pdev;
> int rc, val;
>
> if (!qp)
> return;
>
> + pdev = ntb_query_pdev(qp->ndev);
> qp->client_ready = NTB_LINK_DOWN;
>
> rc = ntb_read_local_spad(qp->ndev, QP_LINKS, );
> @@ -1408,6 +1411,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_down);
> */
> bool ntb_transport_link_query(struct ntb_transport_qp *qp)
> {
> + if (!qp)
> + return false;
> +
> return qp->qp_link == NTB_LINK_UP;
> }
> EXPORT_SYMBOL_GPL(ntb_transport_link_query);
> @@ -1422,6 +1428,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_query);
> */
> unsigned char ntb_transport_qp_num(struct ntb_transport_qp *qp)
> {
> + if (!qp)
> + return 0;
> +
> return qp->qp_num;
> }
> EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
> @@ -1436,6 +1445,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
> */
> unsigned int ntb_transport_max_size(struct ntb_transport_qp *qp)
> {
> + if (!qp)
> + return 0;
> +
> return qp->tx_max_frame - sizeof(struct ntb_payload_header);
> }
> EXPORT_SYMBOL_GPL(ntb_transport_max_size);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] NTB: variable dereferenced before check
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jon Mason "
commit 186f27ff9f9ec5c110739ced88ce9f8fca053882 upstream
Correct instances of variable dereferencing before checking its value on
the functions exported to the client drivers. Also, add sanity checks
for all exported functions.
Reported-by: Dan Carpenter
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_transport.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index e0bdfd7..74c5812 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -1210,12 +1210,14 @@ EXPORT_SYMBOL_GPL(ntb_transport_create_queue);
*/
void ntb_transport_free_queue(struct ntb_transport_qp *qp)
{
- struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
+ struct pci_dev *pdev;
struct ntb_queue_entry *entry;
if (!qp)
return;
+ pdev = ntb_query_pdev(qp->ndev);
+
cancel_delayed_work_sync(>link_work);
ntb_unregister_db_callback(qp->ndev, qp->qp_num);
@@ -1371,12 +1373,13 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_up);
*/
void ntb_transport_link_down(struct ntb_transport_qp *qp)
{
- struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
+ struct pci_dev *pdev;
int rc, val;
if (!qp)
return;
+ pdev = ntb_query_pdev(qp->ndev);
qp->client_ready = NTB_LINK_DOWN;
rc = ntb_read_local_spad(qp->ndev, QP_LINKS, );
@@ -1408,6 +1411,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_down);
*/
bool ntb_transport_link_query(struct ntb_transport_qp *qp)
{
+ if (!qp)
+ return false;
+
return qp->qp_link == NTB_LINK_UP;
}
EXPORT_SYMBOL_GPL(ntb_transport_link_query);
@@ -1422,6 +1428,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_query);
*/
unsigned char ntb_transport_qp_num(struct ntb_transport_qp *qp)
{
+ if (!qp)
+ return 0;
+
return qp->qp_num;
}
EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
@@ -1436,6 +1445,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
*/
unsigned int ntb_transport_max_size(struct ntb_transport_qp *qp)
{
+ if (!qp)
+ return 0;
+
return qp->tx_max_frame - sizeof(struct ntb_payload_header);
}
EXPORT_SYMBOL_GPL(ntb_transport_max_size);
--
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: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On Mon, May 20, 2013 at 09:03:27AM +0800, Chen Gang wrote: > On 05/18/2013 07:06 PM, Ming Lei wrote: > > Hi, > > > > On Fri, May 17, 2013 at 1:43 PM, Chen Gang wrote: > >> Hello All: > >> > >> I searched 'arch/*' and 'drivers/*' sub-directory, all of them are 'obey > >> this rule', even in device_unregister() itself, it also firstly calls > >> device_remove_file(), then call kobject_del(). > >> > >> But after read the related code (fs/sysfs/*, drivers/base/core.c), it > >> seems kobject_del() -> sysfs_remove_dir() which will release all related > >> things (can instead of device_remove_file()). > >> > >> So in fact, we need not call device_remove_file() before call > >> device_unregister(), is it correct ? > > > > Looks it is correct but it is a bit implicit. > > > > If really no other members reply within a week, we should treat your > opinion (or suggestion) as the final result conclusion within > linux-kernel@vger.kernel.org. :-) I have no idea what you mean by this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cdrom: gdrom: fix device number leak
"repost with Jens Axboe added" suggest by Tejun Heo
without this patch, gdrom_major will leak when gd.cd_info alloc faild
Signed-off-by: Libo Chen
---
drivers/cdrom/gdrom.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index 4afcb65..5980cb9 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -830,9 +830,9 @@ probe_fail_cdrom_register:
del_gendisk(gd.disk);
probe_fail_no_disk:
kfree(gd.cd_info);
+probe_fail_no_mem:
unregister_blkdev(gdrom_major, GDROM_DEV_NAME);
gdrom_major = 0;
-probe_fail_no_mem:
pr_warning("Probe failed - error is 0x%X\n", err);
return err;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: renesas-tpu: Add missing pwmchip_remove() call in tpu_remove()
On Sun, May 19, 2013 at 04:22:21PM +0200, Laurent Pinchart wrote:
> Hi Axel,
>
> Thank you for the patch.
>
> On Sunday 19 May 2013 13:45:31 Axel Lin wrote:
> > Signed-off-by: Axel Lin
> > ---
> > drivers/pwm/pwm-renesas-tpu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/pwm-renesas-tpu.c b/drivers/pwm/pwm-renesas-tpu.c
> > index 8e6d8d7..351addd 100644
> > --- a/drivers/pwm/pwm-renesas-tpu.c
> > +++ b/drivers/pwm/pwm-renesas-tpu.c
> > @@ -444,7 +444,7 @@ static int tpu_remove(struct platform_device *pdev)
> >
> > pm_runtime_disable(>dev);
> >
> > - return 0;
> > + return pwmchip_remove(>chip);
>
> Could you please move that line at the beginning of the function ? There
> would
> be a race condition otherwise, as the user could reenable PWM between the
> tpu_pwm_timer_stop() calls and the pwmchip_remove() call.
>
> Apart from that, the patch looks good.
Also, could you please CC linux...@vger.kernel.org,
that will help me track the change through patchwork.
Thanks!
>
> > }
> >
> > static struct platform_driver tpu_driver = {
>
> --
> Regards,
>
> Laurent Pinchart
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: at91: Fix: Change internal SRAM memory type to "MT_MEMORY_SO"
Signed-off-by: Wenyou Yang
---
arch/arm/mach-at91/setup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index e2f4bdd..d68be6c 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -80,7 +80,7 @@ void __init at91_init_sram(int bank, unsigned long base,
unsigned int length)
desc->pfn = __phys_to_pfn(base);
desc->length = length;
- desc->type = MT_DEVICE;
+ desc->type = MT_MEMORY_SO;
pr_info("AT91: sram at 0x%lx of 0x%x mapped at 0x%lx\n",
base, length, desc->virtual);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Change internal SRAM memory type to "MT_MEMORY_SO"
Hi Russell, This patch is to change the internal SRAM memory type to "MT_MEMORY_SO", the right type. It tested on sama5d3xek boards. It based on v3.10-rc1. Best Regards, Wenyou Yang Wenyou Yang (1): ARM: at91: Fix: Change internal SRAM memory type to "MT_MEMORY_SO" arch/arm/mach-at91/setup.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On 05/18/2013 07:06 PM, Ming Lei wrote: > Hi, > > On Fri, May 17, 2013 at 1:43 PM, Chen Gang wrote: >> Hello All: >> >> I searched 'arch/*' and 'drivers/*' sub-directory, all of them are 'obey >> this rule', even in device_unregister() itself, it also firstly calls >> device_remove_file(), then call kobject_del(). >> >> But after read the related code (fs/sysfs/*, drivers/base/core.c), it >> seems kobject_del() -> sysfs_remove_dir() which will release all related >> things (can instead of device_remove_file()). >> >> So in fact, we need not call device_remove_file() before call >> device_unregister(), is it correct ? > > Looks it is correct but it is a bit implicit. > If really no other members reply within a week, we should treat your opinion (or suggestion) as the final result conclusion within linux-kernel@vger.kernel.org. :-) Thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v7 0/21] sched: power aware scheduling
> Which are the workloads where 'powersaving' mode hurts workload > performance measurably? > > I ran ebizzy on a 2 socket, 16 core, SMT 4 Power machine. Is this a 2 * 16 * 4 LCPUs PowerPC machine? > The power efficiency drops significantly with the powersaving policy of > this patch,over the power efficiency of the scheduler without this patch. > > The below parameters are measured relative to the default scheduler > behaviour. > > A: Drop in power efficiency with the patch+powersaving policy > B: Drop in performance with the patch+powersaving policy > C: Decrease in power consumption with the patch+powersaving policy > > NumThreads AB C > - > 2 33% 36% 4% > 4 31% 33% 3% > 8 28% 30% 3% > 16 31% 33% 4% > > Each of the above run is for 30s. > > On investigating socket utilization,I found that only 1 socket was being > used during all the above threaded runs. As can be guessed this is due > to the group_weight being considered for the threshold metric. > This stacks up tasks on a core and further on a socket, thus throttling > them, as observed by Mike below. > > I therefore think we must switch to group_capacity as the metric for > threshold and use only (rq->utils*nr_running) for group_utils > calculation during non-bursty wakeup scenarios. > This way we are comparing right; the utilization of the runqueue by the > fair tasks and the cpu capacity available for them after being consumed > by the rt tasks. > > After I made the above modification,all the above three parameters came > to be nearly null. However, I am observing the load balancing of the > scheduler with the patch and powersavings policy enabled. It is behaving > very close to the default scheduler (spreading tasks across sockets). > That also explains why there is no performance drop or gain with the > patch+powersavings policy enabled. I will look into this observation and > revert. Thanks a lot for the great testings! Seem tasks per SMT cpu isn't power efficient. And I got the similar result last week. I tested the fspin testing(do endless calculation, in linux-next tree.). when I bind task per SMT cpu, the power efficiency really dropped with most every threads number. but when bind task per core, it has better power efficiency on all threads. Beside to move task depend on group_capacity, another choice is balance task according cpu_power. I did the transfer in code. but need to go through a internal open source process before public them. > Well, it'll lose throughput any time there's parallel execution potential but it's serialized instead.. using average will inevitably stack tasks sometimes, but that's its goal. Hackbench shows it. >>> >>> (but that consolidation can be a winner too, and I bet a nickle it would >>> be for a socket sized pgbench run) >> >> (belay that, was thinking of keeping all tasks on a single node, but >> it'll likely stack the whole thing on a CPU or two, if so, it'll hurt) > > At this point, I would like to raise one issue. > *Is the goal of the power aware scheduler improving power efficiency of > the scheduler or a compromise on the power efficiency but definitely a > decrease in power consumption, since it is the user who has decided to > prioritise lower power consumption over performance* ? > It could be one of reason for this feather, but I could like to make it has better efficiency, like packing tasks according to cpu_power not current group_weight. >> > > Regards > Preeti U Murthy > -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the rr-fixes tree
Hi Rusty,
After merging the rr-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/dma/iovlock.c: In function 'dma_pin_iovec_pages':
drivers/dma/iovlock.c:98:21: error: dereferencing pointer to incomplete type
down_read(>mm->mmap_sem);
^
drivers/dma/iovlock.c:101:11: error: dereferencing pointer to incomplete type
current->mm,
^
drivers/dma/iovlock.c:108:19: error: dereferencing pointer to incomplete type
up_read(>mm->mmap_sem);
^
Caused by commit 11227d242a8c ("Hoist memcpy_fromiovec/memcpy_toiovec
into lib/"). Clearly, net/tcp.h was indirectly including sched.h or
asm/current.h. Changing inclusions is fraught with problems since people
do not follow Rule 1 (in Documentation/SubmitChecklist) consistently. :-(
I have used the rr-fixes tree from next-20130515 (since the fix in
rr-fixes in next-20130516/7 conflicts with the better fix now in Linus'
tree) for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp76Rgl5YvYG.pgp
Description: PGP signature
Re: [PATCH] leds: leds-gpio: reserve gpio before using it
Friday, May 17, 2013 4:49 PM, Timo Teras wrote: > > This reverts commit a99d76f (leds: leds-gpio: use gpio_request_one) > and commit 2d7c22f (leds: leds-gpio: set devm_gpio_request_one() > flags param correctly) which was a fix of the first one. > > The conversion to devm_gpio_request in commit e3b1d44c (leds: > leds-gpio: use devm_gpio_request_one) is not reverted. > > The problem is that gpio_cansleep() and gpio_get_value_cansleep() > calls can crash if the gpio is not first reserved. Incidentally this > same bug existed earlier and was fixed similarly in commit d95cbe61 > (leds: Fix potential leds-gpio oops). But the OOPS is real. It happens > when GPIOs are provided by module which is not yet loaded. > > So this fixes the following BUG during my ALIX boot (3.9.2-vanilla): > > BUG: unable to handle kernel NULL pointer dereference at 004c > IP: [] __gpio_cansleep+0xe/0x1a > *pde = > Oops: [#1] SMP > Modules linked in: leds_gpio(+) via_rhine mii cs5535_mfd mfd_core > geode_rng rng_core geode_aes isofs nls_utf8 nls_cp437 vfat fat > ata_generic pata_amd pata_cs5536 pata_acpi libata ehci_pci ehci_hcd > ohci_hcd usb_storage usbcore usb_common sd_mod scsi_mod squashfs loop > Pid: 881, comm: modprobe Not tainted 3.9.2 #1-Alpine > EIP: 0060:[] EFLAGS: 00010282 CPU: 0 > EIP is at __gpio_cansleep+0xe/0x1a > EAX: EBX: cf364018 ECX: c132b8b9 EDX: > ESI: c13993a4 EDI: c1399370 EBP: cded9dbc ESP: cded9dbc > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > CR0: 8005003b CR2: 004c CR3: 0f0c4000 CR4: 0090 > DR0: DR1: DR2: DR3: > DR6: 0ff0 DR7: 0400 > Process modprobe (pid: 881, ti=cded8000 task=cf094aa0 task.ti=cded8000) > Stack: > cded9de0 d09471cb c1399260 cf364014 c1399260 c1399254 > d0949014 cded9df4 c118cd59 c1399260 d0949014 d0949014 cded9e08 c118ba47 > c1399260 d0949014 c1399294 cded9e1c c118bb75 cded9e24 d0949014 > Call Trace: > [] gpio_led_probe+0xba/0x203 [leds_gpio] > [] platform_drv_probe+0x26/0x48 > [] driver_probe_device+0x75/0x15c > [] __driver_attach+0x47/0x63 > [] bus_for_each_dev+0x3c/0x66 > [] driver_attach+0x14/0x16 > [] ? driver_probe_device+0x15c/0x15c > [] bus_add_driver+0xbd/0x1bc > [] ? 0xd08b3fff > [] ? 0xd08b3fff > [] driver_register+0x74/0xec > [] ? 0xd08b3fff > [] platform_driver_register+0x38/0x3a > [] gpio_led_driver_init+0xd/0x1000 [leds_gpio] > [] do_one_initcall+0x6b/0x10f > [] ? 0xd08b3fff > [] load_module+0x1631/0x1907 > [] ? insert_vmalloc_vmlist+0x14/0x43 > [] ? __vmalloc_node_range+0x13e/0x15f > [] sys_init_module+0x62/0x77 > [] syscall_call+0x7/0xb > EIP: [] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc > CR2: 004c > ---[ end trace 5308fb20d2514822 ]--- > > Signed-off-by: Timo Ter?s > Cc: Jingoo Han Acked-by: Jingoo Han I look at what happens in leds-gpio. As you mentioned, devm_gpio_request() should be called before gpio_cansleep() and gpio_get_value_cansleep are called. Thank you for sending the patch. Best regards, Jingoo Han > Cc: Sachin Kamat > Cc: Raphael Assenat > Cc: Trent Piepho > Cc: Javier Martinez Canillas > Cc: Arnaud Patard > Cc: Ezequiel Garcia > --- > drivers/leds/leds-gpio.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c > index a0d931b..b02b679 100644 > --- a/drivers/leds/leds-gpio.c > +++ b/drivers/leds/leds-gpio.c > @@ -107,6 +107,10 @@ static int create_gpio_led(const struct gpio_led > *template, > return 0; > } > > + ret = devm_gpio_request(parent, template->gpio, template->name); > + if (ret < 0) > + return ret; > + > led_dat->cdev.name = template->name; > led_dat->cdev.default_trigger = template->default_trigger; > led_dat->gpio = template->gpio; > @@ -126,10 +130,7 @@ static int create_gpio_led(const struct gpio_led > *template, > if (!template->retain_state_suspended) > led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME; > > - ret = devm_gpio_request_one(parent, template->gpio, > - (led_dat->active_low ^ state) ? > - GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW, > - template->name); > + ret = gpio_direction_output(led_dat->gpio, led_dat->active_low ^ state); > if (ret < 0) > return ret; > > -- > 1.8.2.3 >
linux-next: manual merge of the usb.current tree with Linus' tree
Hi Greg,
Today's linux-next merge of the usb.current tree got a conflict in
drivers/usb/host/ohci-nxp.c between commit bb522812a1a6
("drivers/usb/host: don't check resource with devm_ioremap_resource")
from Linus' tree and commit b3517d5de80e ("usb: ohci: fix goto wrong tag
in err case") from the usb.current tree.
The former remove a bit of code modified by the latter, so I did that and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpccBrxkSni6.pgp
Description: PGP signature
[PATCH testing] mrf24j40: Move INIT_COMPLETION to before the packet is sent
This avoids a race condition where the tx_complete interrupt could happen before the completion is initialized. --- David H, Try this out and see if it changes anything for you. I put a bunch of schedule_timeout()s in mrf24j40_tx() to basically guarantee that a reception will happen during mrf24j40_tx(), and it seems to work. It would not work before with said schedule_timeout() calls. Alan. --- drivers/net/ieee802154/mrf24j40.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c index 556151d..0ea2a5a 100644 --- a/drivers/net/ieee802154/mrf24j40.c +++ b/drivers/net/ieee802154/mrf24j40.c @@ -345,6 +345,8 @@ static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb) if (ret) goto err; + INIT_COMPLETION(devrec->tx_complete); + /* Set TXNTRIG bit of TXNCON to send packet */ ret = read_short_reg(devrec, REG_TXNCON, ); if (ret) @@ -355,8 +357,6 @@ static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb) val |= 0x4; write_short_reg(devrec, REG_TXNCON, val); - INIT_COMPLETION(devrec->tx_complete); - /* Wait for the device to send the TX complete interrupt. */ ret = wait_for_completion_interruptible_timeout( >tx_complete, -- 1.7.11.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: question about the pwm tree
Hi Thierry, I noticed that you changed the email address for the maintainer of the pwm tree in the MAINTAINERS file. should I use this new address as your contact for linux-next as well? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpI7a6E0qm98.pgp Description: PGP signature
Re: [PATCHv11 3/4] zswap: add to mm/
On Fri, May 17, 2013 at 05:54:18PM +0100, Mel Gorman wrote: > On Mon, May 13, 2013 at 07:40:02AM -0500, Seth Jennings wrote: > > zswap is a thin compression backend for frontswap. It receives pages from > > frontswap and attempts to store them in a compressed memory pool, resulting > > in > > an effective partial memory reclaim and dramatically reduced swap device > > I/O. > > > > potentially reduces IO. No guarantees. Sorry, I was in marketing mode I guess. > > Additionally, in most cases, pages can be retrieved from this compressed > > store > > much more quickly than reading from tradition swap devices resulting in > > faster > > performance for many workloads. > > > > While this is likely, it's also not necessarily true if the swap device > is particularly fast. Also, swap devices can be asynchronously written, > is the same true for zswap? I doubt it as I would expect the compression > operation to slow down pages being added to swap cache. Same here. The compression happens synchronously at pageout() time, more precisely the frontswap_store() in swap_writepage(). The advantage here is that pages synchronously stored in zswap can be immediately reclaimed in shrink_page_list(). > > > It also has support for evicting swap pages that are currently compressed in > > zswap to the swap device on an LRU(ish) basis. > > I know I initially suggested an LRU but don't worry about this thing > being an LRU too much. A FIFO list would be just fine as the pages are > presumably idle if they ended up in zswap in the first place. The LRU stuff is already in zbud and doesn't add much complexity. It is cheap and understandable so may as well do it I figure. You'll have to select a page one way or another. May as well be consistent with the rest of the MM. > > +/* > > +* statistics > > +**/ > > +/* Number of memory pages used by the compressed pool */ > > +static atomic_t zswap_pool_pages = ATOMIC_INIT(0); > > They underlying allocator should be tracking the number of physical > pages used, not this layer. zbud does track the number of pool pages. This variable just mirrors the zbud value when it has the potential to change so that it is accessible in the zswap debugfs. However, since the conversion to zbud, this atomic isn't inc/dec anymore, just set, so no need to be atomic. > > > +/* The number of compressed pages currently stored in zswap */ > > +static atomic_t zswap_stored_pages = ATOMIC_INIT(0); > > + > > +/* > > + * The statistics below are not protected from concurrent access for > > + * performance reasons so they may not be a 100% accurate. However, > > + * they do provide useful information on roughly how many times a > > + * certain event is occurring. > > +*/ > > +static u64 zswap_pool_limit_hit; > > +static u64 zswap_written_back_pages; > > +static u64 zswap_reject_reclaim_fail; > > +static u64 zswap_reject_compress_poor; > > +static u64 zswap_reject_alloc_fail; > > +static u64 zswap_reject_kmemcache_fail; > > +static u64 zswap_duplicate_entry; > > + > > Document what these mean. Will do. > > > +/* > > +* tunables > > +**/ > > +/* Enable/disable zswap (disabled by default, fixed at boot for now) */ > > +static bool zswap_enabled; > > read_mostly Yep. > > > +module_param_named(enabled, zswap_enabled, bool, 0); > > + > > +/* Compressor to be used by zswap (fixed at boot for now) */ > > +#define ZSWAP_COMPRESSOR_DEFAULT "lzo" > > +static char *zswap_compressor = ZSWAP_COMPRESSOR_DEFAULT; > > +module_param_named(compressor, zswap_compressor, charp, 0); > > + > > +/* The maximum percentage of memory that the compressed pool can occupy */ > > +static unsigned int zswap_max_pool_percent = 20; > > +module_param_named(max_pool_percent, > > + zswap_max_pool_percent, uint, 0644); > > + > > This will need additional love in the future. If you have an 8 node machine > then zswap pool could completely exhaust a single NUMA node with this > parameter. This is pretty much a big fat hammer that stops zswap getting > compltely out of control and taking over the system but it'll need some > sort of sensible automatic resizing based on system activity in the future. > It's not an obstacle to merging because you have to start somewhere but > the fixed-pool size thing is fugly and you should plan on putting it down > in the future. Agreed, it is a starting point and making this policy better and NUMA-aware is at the top of my TODO list. > > > +/* > > + * Maximum compression ratio, as as percentage, for an acceptable > > + * compressed page. Any pages that do not compress by at least > > + * this ratio will be rejected. > > +*/ > > +static unsigned int zswap_max_compression_ratio = 80; > > +module_param_named(max_compression_ratio, > > + zswap_max_compression_ratio, uint, 0644); > > + > > I would be very surprised if a user
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
Randy Dunlap writes:
> On 05/16/13 16:42, Rusty Russell wrote:
>> Joe Perches writes:
>>> On Thu, 2013-05-16 at 13:04 +0930, Rusty Russell wrote:
Asias He writes:
> On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
>>> []
> Other users are using memcpy_fromiovec and friends outside net. It seems
> a good idea to put it in a util library. e.g. crypto/algif_skcipher.c
> which also depends on NET for it.
>>>
>>> []
Subject: Hoist memcpy_fromiovec into lib/
>>>
>>> You'll need the "friends" memcpy_toiovec too.
>>>
>>> $ git grep -E \bmemcpy\w+iovec\w*"
>>> crypto/algif_hash.c:err = memcpy_toiovec(msg->msg_iov, ctx->result,
>>> len);
>>> crypto/algif_skcipher.c:err =
>>> memcpy_fromiovec(page_address(sg_page(sg)) +
>>> crypto/algif_skcipher.c:err =
>>> memcpy_fromiovec(page_address(sg_page(sg + i)),
>>> drivers/dma/iovlock.c:#include /* for memcpy_toiovec */
>>> drivers/dma/iovlock.c: return memcpy_toiovec(iov, kdata, len);
>>> drivers/dma/iovlock.c: err = memcpy_toiovec(iov, vaddr + offset,
>>> len);
>>> drivers/isdn/mISDN/socket.c:if (memcpy_fromiovec(skb_put(skb, len),
>>> msg->msg_iov, len)) {
>>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
>>> memcpy_fromiovec((u8 *)va + page_o
>>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
>>> memcpy_toiovec(iov, (u8 *)va + pag
>>
>> Fascinating. These all indirectly depend on NET, so there's no problem
>> at the moment. But it is a bit weird...
>>
>> crypto/algif_hash.c: depends on CRYPTO_USER_API_HASH -> NET
>> crypto/algif_skcipher.c: depends on CRYPTO_USER_API_SKCIPHER -> NET
>> drivers/dma/iovlock.c: depends on NET_DMA -> NET
>> drivers/isdn/mISDN/socket.c: depends on MISDN -> ISDN -> NET
>> drivers/misc/vmw_vmci/vmci_queue_pair.c: depends on VMCI -> NET
>>
>> Patch welcome.
>>
>> Meanwhile, to avoid more bikeshedding I've put the patch I posted with
>> all acks in my fixes branch. One cycle through linux-next, then
>> straight to Linus.
>>
>
> I agree with whoever suggested that more be moved into /lib.
> E.g., drivers/misc/vmw_vmci/Kconfig uses "depends on NET" because the
> code there uses both memcpy_toiovec() and memcpy_fromiovec().
> See commit ID 6d4f0139d642c45411a47879325891ce2a7c164a.
(CC's trimmed).
You Acked that commit :(
At a glance, the only way to drive the vmw_vmci device is through
net/vmw_vsock/vmci_transport.c, so without NET it's useless? But let's
keep it neat anyway. This was compiletested with CONFIG_VMCI,
CONFIG_DMA_ENGINE and !CONFIG_NET.
Thanks,
Rusty.
From: Rusty Russell
Subject: [PATCH] Hoist memcpy_fromiovec/memcpy_toiovec into lib/
ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!
That function is only present with CONFIG_NET. Turns out that
crypto/algif_skcipher.c also uses that outside net, but it actually
needs sockets anyway.
In addition, commit 6d4f0139d642c45411a47879325891ce2a7c164a added
CONFIG_NET dependency to CONFIG_VMCI for memcpy_toiovec, so hoist
that function and revert that commit too.
socket.h already include uio.h, so no callers *need* updating,
though I update the obvious ones.
Reported-by: Randy Dunlap
Acked-by: David S. Miller
Acked-by: Michael S. Tsirkin
Signed-off-by: Rusty Russell
diff --git a/drivers/dma/iovlock.c b/drivers/dma/iovlock.c
index bb48a57..6943deb66 100644
--- a/drivers/dma/iovlock.c
+++ b/drivers/dma/iovlock.c
@@ -28,7 +28,7 @@
#include
#include
#include
-#include /* for memcpy_toiovec */
+#include /* for memcpy_toiovec */
#include
#include
diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig
index ea98f7e..39c2eca 100644
--- a/drivers/misc/vmw_vmci/Kconfig
+++ b/drivers/misc/vmw_vmci/Kconfig
@@ -4,7 +4,7 @@
config VMWARE_VMCI
tristate "VMware VMCI Driver"
- depends on X86 && PCI && NET
+ depends on X86 && PCI
help
This is VMware's Virtual Machine Communication Interface. It enables
high-speed communication between host and guest in a virtual
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index d94245d..8ff2e5e 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -23,7 +23,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 428c37a..33bf2df 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -305,7 +305,6 @@ struct ucred {
extern void cred_to_ucred(struct pid *pid, const struct cred *cred, struct
ucred *ucred);
-extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
extern int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
int offset, int len);
extern int csum_partial_copy_fromiovecend(unsigned char
pipe/fifo, set exception for select() when read end is not open
I've been looking at the gule hacks I have to use to get inotifywait to work in shell scripts. So I figgered I would hack inotifywait to look at exceptions in its select() loop. No joy. inotifywait loops using select() to look for changes to at least one inotify FD. Whenever it sees a change, it reads the event and sends it to stdout. Cool. This works well and uses little CPU time. But there's a problem. Suppose you have inotifywait monitoring a specific file for a change, such as "wait for this file to be deleted." And you have piped inotifywait to "while read a b c". The problem is that when the 'while' loop gets the DELETE event, it does what is needed and exits. And it is expected that inotifywait will exit. But because the file it was watching has been deleted and can cause no more events, inotifywait will never receive another event, never return from select(), never write to the pipe, and never know that the pipe's reader exitted. It will never know that it should exit. Then I got to wondering why it is that writing to a pipe is the *only* way to know that the reader end is or has been closed (other than via complicated signalling). And wondering why. Would it be possible to set an exception on a pipe's or fifo's writer FD when the reader FD is not open (when there are no readers or when there are none left)? Would it be reasonable to do this? I imagine a pipe should have a 'last reader closed' exception, while fifos could benefit from that and/or a 'no readers' exception. If this exception existed, inotifywait could watch for read and exception changes using select(). An exception on stdout would almost certainly mean that the pipe has been welded shut, so inotifywait should just exit. This can't be the only example of a program that could benefit from knowing that one of its output pipes is closed without needing to write to the pipe to find out. Thanks, N (Please CC me on replies.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-zigbee-devel] [PATCH 2/2] mrf24j40: Keep the interrupt line enabled
On 05/16/2013 05:34 PM, David Hauweele wrote:
> I have seen the interrupt line going low forever with heavy traffic.
Hi David,
I've been doing some testing today and I can reproduce your issue if I
ping -f both ways simultaneously (after about 3-4 minutes usually). I
think it has more to do with the tx/rx mutual exclusion that you
described in patch 1/1 than it does with the disable/enable IRQ. With
respect to enable/disable irq, I did some checking of other similar
drivers (non-ieee802154) and noticed that many of them use threaded
interrupts. I think this may be closer to the right way to do it.
Are you running a tickless kernel? What is your preemption model? What's
your hardware platform?
> The at86rf230 driver has two isr, one for edge-triggered and another
> for level-triggered interrupt. The latter uses
> disable_irq_nosync/enable_irq which makes sense for level-triggered
> interrupt. Otherwise the interrupt would be triggered again and again
> until the scheduled work read the status register.
>
> However I don't see the use of disable_irq/enable_irq with an
> edge-triggered interrupt. Perhaps I'm missing something. Though I
> don't see any harm using it anyway.
My understanding based on the datasheet is that the interrupt can be
asserted again as soon as INTSTAT is read (which is done in the
workqueue). I guess even if it happens while the workqueue is running,
it's ok.
I think I had a flawed understanding of schedule_work() before, thinking
that it would not schedule a work_struct it if the work_struct was running.
> As you said the interrupt should
> be delayed until enable_irq() is called. In particular when
> CONFIG_HARDIRQS_SW_RESEND is set.
I think I agree with you. I'll send you a patch to try with threaded
interrupts to try.
I'm trying to determine exactly what's the cause of the interrupt line
being stuck low.
Alan.
>
> 2013/5/14 Alan Ott :
>> On 5/9/13 11:19 AM, David Hauweele wrote:
>>> Disabling the interrupt line could miss an IRQ and leave the line into a
>>> low state hence locking the driver.
>>>
>> Have you observed this? My understanding is that the interrupt won't be lost
>> but instead delayed until enable_irq() is called.
>>
>> I got this pattern from the other 802.15.4 drivers. Perhaps my understanding
>> is wrong.
>>
>>
>>
>>> Signed-off-by: David Hauweele
>>> ---
>>> drivers/net/ieee802154/mrf24j40.c |7 +--
>>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/net/ieee802154/mrf24j40.c
>>> b/drivers/net/ieee802154/mrf24j40.c
>>> index 1e3ddf3..6ef32f7 100644
>>> --- a/drivers/net/ieee802154/mrf24j40.c
>>> +++ b/drivers/net/ieee802154/mrf24j40.c
>>> @@ -603,8 +603,6 @@ static irqreturn_t mrf24j40_isr(int irq, void *data)
>>> {
>>> struct mrf24j40 *devrec = data;
>>>
>>> - disable_irq_nosync(irq);
>>> -
>>> schedule_work(>irqwork);
>>>
>>> return IRQ_HANDLED;
>>> @@ -619,7 +617,7 @@ static void mrf24j40_isrwork(struct work_struct *work)
>>> /* Read the interrupt status */
>>> ret = read_short_reg(devrec, REG_INTSTAT, );
>>> if (ret)
>>> - goto out;
>>> + return;
>>>
>>> /* Check for TX complete */
>>> if (intstat & 0x1)
>>> @@ -628,9 +626,6 @@ static void mrf24j40_isrwork(struct work_struct *work)
>>> /* Check for Rx */
>>> if (intstat & 0x8)
>>> schedule_work(>rxwork);
>>> -
>>> -out:
>>> - enable_irq(devrec->spi->irq);
>>> }
>>>
>>> static void mrf24j40_rxwork(struct work_struct *work)
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Reporting traffic queue distribution statistics through ethtool
Hi Michael,
Comments inline...
-Original Message-
From: Michael S. Tsirkin [mailto:m...@redhat.com]
Sent: Sunday, May 19, 2013 1:03 PM
To: Narasimhan, Sriram
Cc: ru...@rustcorp.com.au; virtualizat...@lists.linux-foundation.org;
k...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
Jason Wang
Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution
statistics through ethtool
On Sun, May 19, 2013 at 04:09:48PM +, Narasimhan, Sriram wrote:
> Hi Michael,
>
> I was getting all packets on the same inbound queue which
> is why I added this support to virtio-net (and some more
> instrumentation at tun as well). But, it turned out to be
> my misconfiguration - I did not enable IFF_MULTI_QUEUE on
> the tap device, so the real_num_tx_queues on tap netdev was
> always 1 (no tx distribution at tap).
Interesting that qemu didn't fail.
[Sriram] void tun_set_real_num_tx_queues() does not return
the EINVAL return from netif_set_real_num_tx_queues() for
txq > dev->num_tx_queues (which would be the case if the
tap device were not created with IFF_MULTI_QUEUE). I think
it would be better to fix the code to disable the new
queue and fail tun_attach() in this scenario. If you
agree, I can go ahead and create a separate patch for that.
> I am thinking about
> adding a -q option to tunctl to specify multi-queue flag on
> the tap device.
Absolutely.
[Sriram] OK, let me do that.
> Yes, number of exits will be most useful. I will look into
> adding the other statistics you mention.
>
> Sriram
Pls note you'll need to switch to virtqueue_kick_prepare
to detect exits: virtqueue_kick doesn't let you know
whether there was an exit.
Also, it's best to make this a separate patch from the one
adding per-queue stats.
[Sriram] OK, I will cover only the per-queue statistics in
this patch. Also, I will address the indentation/data
structure name points that you mentioned in your earlier
email and send a new revision for this patch.
Sriram
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Sunday, May 19, 2013 4:28 AM
> To: Narasimhan, Sriram
> Cc: ru...@rustcorp.com.au; virtualizat...@lists.linux-foundation.org;
> k...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution
> statistics through ethtool
>
> On Thu, May 16, 2013 at 01:24:29PM -0700, Sriram Narasimhan wrote:
> > This patch allows virtio-net driver to report traffic distribution
> > to inbound/outbound queues through ethtool -S. The per_cpu
> > virtnet_stats is split into receive and transmit stats and are
> > maintained on a per receive_queue and send_queue basis.
> > virtnet_stats() is modified to aggregate interface level statistics
> > from per-queue statistics. Sample output below:
> >
>
> Thanks for the patch. The idea itself looks OK to me.
> Ben Hutchings already sent some comments
> so I won't repeat them. Some minor more comments
> and questions below.
>
> > NIC statistics:
> > rxq0: rx_packets: 4357802
> > rxq0: rx_bytes: 292642052
> > txq0: tx_packets: 824540
> > txq0: tx_bytes: 55256404
> > rxq1: rx_packets: 0
> > rxq1: rx_bytes: 0
> > txq1: tx_packets: 1094268
> > txq1: tx_bytes: 73328316
> > rxq2: rx_packets: 0
> > rxq2: rx_bytes: 0
> > txq2: tx_packets: 1091466
> > txq2: tx_bytes: 73140566
> > rxq3: rx_packets: 0
> > rxq3: rx_bytes: 0
> > txq3: tx_packets: 1093043
> > txq3: tx_bytes: 73246142
>
> Interesting. This example implies that all packets are coming in
> through the same RX queue - is this right?
> If yes that's worth exploring - could be a tun bug -
> and shows how this patch is useful.
>
> > Signed-off-by: Sriram Narasimhan
>
> BTW, while you are looking at the stats, one other interesting
> thing to add could be checking more types of stats: number of exits,
> queue full errors, etc.
>
> > ---
> > drivers/net/virtio_net.c | 157
> > +-
> > 1 files changed, 128 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 3c23fdc..3c58c52 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -41,15 +41,46 @@ module_param(gso, bool, 0444);
> >
> > #define VIRTNET_DRIVER_VERSION "1.0.0"
> >
> > -struct virtnet_stats {
> > - struct u64_stats_sync tx_syncp;
> > +struct virtnet_rx_stats {
> > struct u64_stats_sync rx_syncp;
> > - u64 tx_bytes;
> > + u64 rx_packets;
> > + u64 rx_bytes;
> > +};
> > +
> > +struct virtnet_tx_stats {
> > + struct u64_stats_sync tx_syncp;
> > u64 tx_packets;
> > + u64 tx_bytes;
> > +};
> >
> > - u64 rx_bytes;
> > - u64 rx_packets;
>
> I think maintaining the stats in a per-queue data structure like this is
> fine. if # of CPUs == # of queues which is typical, we use same
[PATCH] ipc,sem: move restart loop to do_smart_update
On Sat, 18 May 2013 15:48:06 +0200 Manfred Spraul wrote: > Hi Rik, > > I like your change to the ipc/sem locking: > A scheme with a per-semaphore lock and without the overhead of always > acquiring both the global and the per-semaphore lock. > > But: > 1) I found one bug with your sem locking changes: > If > - a complex operation is sleeping [would be woken up by update_queue(,-1)] > - a simple op is sleeping > - the success of the simple op would allow the complex op to complete > [i.e.: update_queue(,sem_num) changes the semaphore value to the > value that the complex op waits on] > - an operation wakes up the simple op. Are you referring to eg. a complex operation that waits for several semaphores to turn 0, and a simple op that subtracts 1 from a semaphore, turning it into 0? > then the complex op is not woken up. > > One fix would be a loop in do_smart_update(): > - first check the global queue > - then the per-semaphore queues > - if one of the per-semaphore queues made progress: check the global > queue again > - if the global queue made progress: check the per semaphore queues again > ... Would that be as simple as making do_smart_update() loop back to the top if update_queue on a single semaphore's queue returns a non-zero value (something was changed), and there are complex operations pending? I implemented that in the patch below. > 2) Your patches remove FIFO ordering of the wakeups: > As far as I can see complex ops are now preferred over simple ops. > It's not a bug, noone exept linux implements FIFO. > But the comment it line 28 should be updated > > Should I write a patch, do you want to fix it yourself? You seem to have looked at this problem more closely than I have, so I would appreciate it if you could review this patch :) ---8<--- Subject: ipc,sem: move restart loop to do_smart_update A complex operation may be sleeping on a semaphore to become a certain value. A sleeping simple operation may turn the semaphore into that value. Having the restart loop inside update_queue means we may be missing the complex operation (which lives on a different queue), and result in a semaphore lockup. The lockup can be avoided by moving the restart loop into do_smart_update, so the list of pending complex operations will also be checked if required. Signed-off-by: Rik van Riel Reported-by: Manfred Spraul --- ipc/sem.c | 44 +--- 1 file changed, 21 insertions(+), 23 deletions(-) diff --git a/ipc/sem.c b/ipc/sem.c index a7e40ed..3d71c3c 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -25,8 +25,6 @@ * This file implements System V semaphores. * * User space visible behavior: - * - FIFO ordering for semop() operations (just FIFO, not starvation - * protection) * - multiple semaphore operations that alter the same semaphore in * one semop() are handled. * - sem_ctime (time of last semctl()) is updated in the IPC_SET, SETVAL and @@ -51,8 +49,7 @@ * count_semzcnt() * - the task that performs a successful semop() scans the list of all * sleeping tasks and completes any pending operations that can be fulfilled. - * Semaphores are actively given to waiting tasks (necessary for FIFO). - * (see update_queue()) + * Semaphores are actively given to waiting tasks (see update_queue()). * - To improve the scalability, the actual wake-up calls are performed after * dropping all locks. (see wake_up_sem_queue_prepare(), * wake_up_sem_queue_do()) @@ -68,9 +65,9 @@ * modes for the UNDO variables are supported (per process, per thread) * (see copy_semundo, CLONE_SYSVSEM) * - There are two lists of the pending operations: a per-array list - * and per-semaphore list (stored in the array). This allows to achieve FIFO - * ordering without always scanning all pending operations. - * The worst-case behavior is nevertheless O(N^2) for N wakeups. + * and per-semaphore list (stored in the array). The per-array list is + * used for calls that do multiple semaphore operations in one semop call. + * The worst-case behavior is O(N^2) for N wakeups. */ #include @@ -606,7 +603,7 @@ static void unlink_queue(struct sem_array *sma, struct sem_queue *q) * @sma: semaphore array * @q: the operation that just completed * - * update_queue is O(N^2) when it restarts scanning the whole queue of + * do_smart_update is O(N^2) when it restarts scanning the whole queue of * waiting operations. Therefore this function checks if the restart is * really necessary. It is called after a previously waiting operation * was completed. @@ -671,6 +668,7 @@ static int check_restart(struct sem_array *sma, struct sem_queue *q) * @sma: semaphore array. * @semnum: semaphore that was modified. * @pt: list head for the tasks that must be woken up. + * @restart: did a semop change something that may require a restart? * * update_queue must be called after a semaphore in a semaphore array * was modified. If
Re: [PATCH 1/1] 6lowpan: Fix fragmentation with link-local compressed addresses
Hello, There is a patch which fixes link-local address uncompression: http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1717 I came across a similar solution but didn't submit it as another patch already existed. This patch instead focus on fragmented packet with link-local address compression, which is related but a different bug. 2013/5/19 Alexander Aring : > Hi David, > > can you use a link-layer address on the current net-next kernel? > > I am asking because I can't use a link-layer address currently. > Your patch doesn't help to solve my problem with link-layer addresses. > > > To your patch: > > We get the link-layer addresses from skb not from the allocated > frame->skb. > > Here is the code: > > _saddr = mac_cb(skb)->sa.hwaddr; > _daddr = mac_cb(skb)->da.hwaddr; > > Here is skb != frame->skb so we don't need to copy it to frame->skb->cb > because we already the link-layer addresses from skb->cb. > > Is there another place in the code where we get the link-layer addresses > from allocated "frame" structure? frame->skb is used to reassemble the 6lowpan packet when new fragments are received. This is the 'fragments assembling' switch at the beginning of lowpan_process_data(). It will reassemble fragments until the packet is successfully reassembled. Once it is, skb is replaced: dev_kfree_skb(skb); skb = frame->skb; kfree(frame); And the process continues as with other 6lowpan packets. In particular: _saddr = mac_cb(skb)->sa.hwaddr; _daddr = mac_cb(skb)->da.hwaddr; Several lines later there are: err = lowpan_uncompress_addr(skb, , lowpan_llprefix, lowpan_unc_llconf[tmp], skb->data); err = lowpan_uncompress_addr(skb, , lowpan_llprefix, lowpan_unc_llconf[tmp], skb->data); These two lines should use _saddr/_daddr instead of skb->data, which fixes the link-local address uncompression. I'm able to use link-layer addresses with these two patches and it works well. > > Regards > Alex Regards, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv11 2/4] zbud: add to mm/
On Fri, May 17, 2013 at 04:48:37PM +0100, Mel Gorman wrote: > On Mon, May 13, 2013 at 07:40:01AM -0500, Seth Jennings wrote: > > zbud is an special purpose allocator for storing compressed pages. It is > > designed to store up to two compressed pages per physical page. While this > > design limits storage density, it has simple and deterministic reclaim > > properties that make it preferable to a higher density approach when reclaim > > will be used. > > > > zbud works by storing compressed pages, or "zpages", together in pairs in a > > single memory page called a "zbud page". The first buddy is "left > > justifed" at the beginning of the zbud page, and the last buddy is "right > > justified" at the end of the zbud page. The benefit is that if either > > buddy is freed, the freed buddy space, coalesced with whatever slack space > > that existed between the buddies, results in the largest possible free > > region > > within the zbud page. > > > > zbud also provides an attractive lower bound on density. The ratio of zpages > > to zbud pages can not be less than 1. This ensures that zbud can never "do > > harm" by using more pages to store zpages than the uncompressed zpages would > > have used on their own. > > > > This patch adds zbud to mm/ for later use by zswap. > > > > Signed-off-by: Seth Jennings > > I'm not familiar with the code in staging/zcache/zbud.c and this looks > like a rewrite but I'm curious, why was an almost complete rewrite > necessary? The staging code looks like it had debugfs statistics and > the like that would help figure how well the packing was working and so > on. I guess it was probably because it was integrated tightly with other > components in staging but could that not be torn out? I'm guessing you > have a good reason but it'd be nice to see that in the changelog. I'll add a bit about that. > > 4 files changed, 597 insertions(+) > > + * zbud pages are divided into "chunks". The size of the chunks is fixed > > at > > + * compile time and determined by NCHUNKS_ORDER below. Dividing zbud pages > > + * into chunks allows organizing unbuddied zbud pages into a manageable > > number > > + * of unbuddied lists according to the number of free chunks available in > > the > > + * zbud page. > > + * > > Fixing the size of the chunks at compile time is a very strict > limitation! Distributions will have to make that decision for all workloads > that might conceivably use zswap. Having the allocator only deal with pairs > of pages limits the worst-case behaviour where reclaim can generate lots of > IO to free a single physical page. However, the chunk size directly affects > the fragmentation properties, both internal and external, of this thing. > Once NCHUNKS is > 2 it is possible to create a workload that externally > fragments this allocator such that each physical page only holds one > compressed page. If this is a problem for a user then their only option > is to rebuild the kernel which is not always possible. You lost me here. Do you mean NCHUNKS > 2 or NCHUNKS_ORDER > 2? My first guess is that the external fragmentation situation you are referring to is a workload in which all pages compress to greater than half a page. If so, then it doesn't matter what NCHUCNKS_ORDER is, there won't be any pages the compress enough to fit in the < PAGE_SIZE/2 free space that remains in the unbuddied zbud pages. You might also be referring to the fact that if you set NCHUNKS_ORDER to 2 (i.e. there are 4 chunks per zbud page) and you receive an allocation for size (3/4 * PAGE_SIZE) + 1, the allocator will use all 4 chunks for that allocation and the rest of the zbud page is lost to internal fragmentation. That is simply an argument for not choosing a small NCHUNKS_ORDER. > > Please make this configurable by a kernel boot parameter at least. At > a glance it looks like only problem would be that you have to kmalloc > unbuddied[NCHUNKS] in the pool structure but that is hardly of earth > shattering difficulty. Make the variables read_mostly to avoid cache-line > bouncing problems. I am hesitant to make this a tunable without understanding why anyone would want to tune it. It's hard to convey to a user what this tunable would do and what effect it might have. I'm not saying that isn't such a situation. I just don't see one didn't understand your case above. > > Finally, because a review would never be complete without a bitching > session about names -- I don't like the name zbud. Buddy allocators take > a large block of memory and split it iteratively (by halves for binary > buddy allocators but there are variations) until it's a best fit for the > allocation request. A key advantage of such schemes is fast searching for > free holes. That's not what this allocator does and as the page allocator > is a binary buddy allocator in Linux, calling this this a buddy allocator > is a bit misleading. Looks like the existing zbud.c also has this problem > but hey. This
Re: [RFC] drm: i2c: add irq handler for tda998x slave encoder
On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:
> This adds an irq handler for HPD to the tda998x slave encoder driver
> to trigger HPD change instead of polling. The gpio connected to int
> pin of tda998x is passed through platform_data of the i2c client. As
> HPD will ultimately cause EDID read and that will raise an
> EDID_READ_DONE interrupt, the irq handling is done threaded with a
> workqueue to notify drm backend of HPD events.
>
> Signed-off-by: Sebastian Hesselbarth
Okay, I think I get this.. Some comments:
> +static irqreturn_t tda998x_irq_thread(int irq, void *data)
> +{
> + struct drm_encoder *encoder = data;
> + struct tda998x_priv *priv;
> + uint8_t sta, cec, hdmi, lev;
> +
> + if (!encoder)
> + return IRQ_HANDLED;
This won't ever be NULL. The IRQ layer stores the pointer you passed
in request_threaded_irq() and that pointer will continue to point at
that memory until the IRQ is freed. The only way it could be NULL is
if you register using a NULL pointer.
...
> + if (priv->irq < 0) {
> + for (i = 100; i > 0; i--) {
> + uint8_t val = reg_read(encoder, REG_INT_FLAGS_2);
IRQ 0 is the cross-arch "no interrupt" number. So just use !priv->irq
here and encourage anyone who uses -1 or NO_IRQ to fix their stuff. :)
> + struct tda998x_priv *priv = to_tda998x_priv(encoder);
> +
> + /* announce polling if no irq is available */
> + if (priv->irq < 0)
Same here.
> @@ -1122,7 +1197,9 @@ tda998x_encoder_init(struct i2c_client *client,
>
> priv->current_page = 0;
> priv->cec = i2c_new_dummy(client->adapter, 0x34);
> + priv->irq = -EINVAL;
And just initialize to zero. (it's allocated by kzalloc already right?
So that shouldn't be necessary.)
> diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
> index 41f799f..1838703 100644
> --- a/include/drm/i2c/tda998x.h
> +++ b/include/drm/i2c/tda998x.h
> @@ -20,4 +20,8 @@ struct tda998x_encoder_params {
> int swap_f, mirr_f;
> };
>
> +struct tda998x_platform_data {
> + int int_gpio;
> +};
> +
Should be combined with tda998x_encoder_params - the platform data is
really supposed to be passed to set_config - see this in drm_encoder_slave.c:
* If @info->platform_data is non-NULL it will be used as the initial
* slave config.
...
err = encoder_drv->encoder_init(client, dev, encoder);
if (err)
goto fail_unregister;
if (info->platform_data)
encoder->slave_funcs->set_config(>base,
info->platform_data);
So any platform data set will be passed into the set_config function...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 10/10] kernel: might_fault does not imply might_sleep
On Sun, May 19, 2013 at 04:23:22PM -0400, Steven Rostedt wrote: > On Sun, 2013-05-19 at 19:40 +0300, Michael S. Tsirkin wrote: > > > OK I get it. So let me correct myself. The simple code > > that does something like this under a spinlock: > > > preempt_disable > > > pagefault_disable > > > error = copy_to_user > > > pagefault_enable > > > preempt_enable > > > > > is not doing anything wrong and should not get a warning, > > as long as error is handled correctly later. > > Right? > > I came in mid thread and I don't know the context. The context is that I want to change might_fault from might_sleep to might_sleep_if(!in_atomic()) so that above does not trigger warnings even with CONFIG_DEBUG_ATOMIC_SLEEP enabled. > Anyway, the above > looks to me as you just don't want to sleep. Exactly. upstream we can just do pagefault_disable but to make this code -rt ready it's best to do preempt_disable as well. > If you try to copy data to > user space that happens not to be currently mapped for any reason, you > will get an error. Even if the address space is completely valid. Is > that what you want? > > -- Steve > Yes, this is by design. We detect that and bounce the work to a thread outside any locks. Thanks, -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 10/10] kernel: might_fault does not imply might_sleep
On Sun, 2013-05-19 at 19:40 +0300, Michael S. Tsirkin wrote: > OK I get it. So let me correct myself. The simple code > that does something like this under a spinlock: > > preempt_disable > > pagefault_disable > > error = copy_to_user > > pagefault_enable > > preempt_enable > > > is not doing anything wrong and should not get a warning, > as long as error is handled correctly later. > Right? I came in mid thread and I don't know the context. Anyway, the above looks to me as you just don't want to sleep. If you try to copy data to user space that happens not to be currently mapped for any reason, you will get an error. Even if the address space is completely valid. Is that what you want? -- 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 15/20] ARM: mvebu: Remove init_irq declaration in machine description
On Tue, May 14, 2013 at 05:38:48PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for mvebu as well.
>
> Signed-off-by: Maxime Ripard
> Acked-by: Jason Cooper
> ---
> arch/arm/mach-mvebu/armada-370-xp.c | 2 --
> 1 file changed, 2 deletions(-)
Applied to mvebu/cleanup
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] clk: mvebu: restructure SoC clock drivers
Sebastian, On Sat, May 11, 2013 at 03:08:00AM +0200, Sebastian Hesselbarth wrote: > Marvell EBU SoCs share some common clock functions that register core > clocks or clock gates from SoC specific data. These clock drivers are > organized by function and over time the drivers filled up with #ifdefs > to separate different SoC specific code. > > This patch set first adds a new element to clock gate descriptors to > allow to pass clk flags per clock gate. (Patch 1) > > Then it restructures MVEBU clock drivers into common clock setup and > SoC specific files and Kconfig options. The driver's init functions > are also registered to get called with of_clk_init. (Patches 2, 3-6) > > It then switches Dove, Kirkwood, and Armada 370/XP to make use of > of_clk_init instead of mvebu_clocks_init. (Patches 7-9) > > Finally, all obsolete files and Kconfig options are removed. (Patch 10) > > It has been tested on CuBox (Dove) and Dockstar (Kirkwood) by me. > Armada 370 and XP are compile tested only and should get their Tested-by > from Thomas and Gregory, respectively. > > @Mike: As this only touches MVEBU related code, I suggest to take it > all through the corresponding ARM branch. > > Sebastian Hesselbarth (10): > clk: mvebu: introduce per-clock-gate flags > clk: mvebu: add common clock functions for core clk and clk gating > clk: mvebu: add Dove SoC-centric clock init > clk: mvebu: add Kirkwood SoC-centric clock init > clk: mvebu: add Armada 370 SoC-centric clock init > clk: mvebu: add Armada XP SoC-centric clock init > ARM: dove: move DT boards to SoC-centric clock init > ARM: kirkwood: move DT boards to SoC-centric clock init > ARM: mvebu: move DT boards to SoC-centric clock init > clk: mvebu: desintegrate obsolete file > > arch/arm/mach-dove/Kconfig |3 +- > arch/arm/mach-dove/board-dt.c |3 +- > arch/arm/mach-dove/common.c |1 - > arch/arm/mach-kirkwood/Kconfig |3 +- > arch/arm/mach-kirkwood/board-dt.c |3 +- > arch/arm/mach-mvebu/Kconfig |5 +- > arch/arm/mach-mvebu/armada-370-xp.c |4 +- > drivers/clk/mvebu/Kconfig | 25 +- > drivers/clk/mvebu/Makefile |8 +- > drivers/clk/mvebu/armada-370.c | 176 + > drivers/clk/mvebu/armada-xp.c | 204 +++ > drivers/clk/mvebu/clk-core.c| 675 > --- > drivers/clk/mvebu/clk-core.h| 18 - > drivers/clk/mvebu/clk-gating-ctrl.c | 250 - > drivers/clk/mvebu/clk-gating-ctrl.h | 22 -- > drivers/clk/mvebu/clk.c | 23 -- > drivers/clk/mvebu/common.c | 163 + > drivers/clk/mvebu/common.h | 48 +++ > drivers/clk/mvebu/dove.c| 194 ++ > drivers/clk/mvebu/kirkwood.c| 247 + > include/linux/clk/mvebu.h | 22 -- > 21 files changed, 1066 insertions(+), 1031 deletions(-) > create mode 100644 drivers/clk/mvebu/armada-370.c > create mode 100644 drivers/clk/mvebu/armada-xp.c > delete mode 100644 drivers/clk/mvebu/clk-core.c > delete mode 100644 drivers/clk/mvebu/clk-core.h > delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.c > delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.h > delete mode 100644 drivers/clk/mvebu/clk.c > create mode 100644 drivers/clk/mvebu/common.c > create mode 100644 drivers/clk/mvebu/common.h > create mode 100644 drivers/clk/mvebu/dove.c > create mode 100644 drivers/clk/mvebu/kirkwood.c > delete mode 100644 include/linux/clk/mvebu.h > --- I've tentatively applied the whole series to mvebu/seb_clk and merged it into for-next. This will get it a few rounds of testing in linux-next until Mike has a chance to review it. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-net: Reporting traffic queue distribution statistics through ethtool
On Sun, May 19, 2013 at 04:09:48PM +, Narasimhan, Sriram wrote:
> Hi Michael,
>
> I was getting all packets on the same inbound queue which
> is why I added this support to virtio-net (and some more
> instrumentation at tun as well). But, it turned out to be
> my misconfiguration - I did not enable IFF_MULTI_QUEUE on
> the tap device, so the real_num_tx_queues on tap netdev was
> always 1 (no tx distribution at tap).
Interesting that qemu didn't fail.
> I am thinking about
> adding a -q option to tunctl to specify multi-queue flag on
> the tap device.
Absolutely.
> Yes, number of exits will be most useful. I will look into
> adding the other statistics you mention.
>
> Sriram
Pls note you'll need to switch to virtqueue_kick_prepare
to detect exits: virtqueue_kick doesn't let you know
whether there was an exit.
Also, it's best to make this a separate patch from the one
adding per-queue stats.
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Sunday, May 19, 2013 4:28 AM
> To: Narasimhan, Sriram
> Cc: ru...@rustcorp.com.au; virtualizat...@lists.linux-foundation.org;
> k...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution
> statistics through ethtool
>
> On Thu, May 16, 2013 at 01:24:29PM -0700, Sriram Narasimhan wrote:
> > This patch allows virtio-net driver to report traffic distribution
> > to inbound/outbound queues through ethtool -S. The per_cpu
> > virtnet_stats is split into receive and transmit stats and are
> > maintained on a per receive_queue and send_queue basis.
> > virtnet_stats() is modified to aggregate interface level statistics
> > from per-queue statistics. Sample output below:
> >
>
> Thanks for the patch. The idea itself looks OK to me.
> Ben Hutchings already sent some comments
> so I won't repeat them. Some minor more comments
> and questions below.
>
> > NIC statistics:
> > rxq0: rx_packets: 4357802
> > rxq0: rx_bytes: 292642052
> > txq0: tx_packets: 824540
> > txq0: tx_bytes: 55256404
> > rxq1: rx_packets: 0
> > rxq1: rx_bytes: 0
> > txq1: tx_packets: 1094268
> > txq1: tx_bytes: 73328316
> > rxq2: rx_packets: 0
> > rxq2: rx_bytes: 0
> > txq2: tx_packets: 1091466
> > txq2: tx_bytes: 73140566
> > rxq3: rx_packets: 0
> > rxq3: rx_bytes: 0
> > txq3: tx_packets: 1093043
> > txq3: tx_bytes: 73246142
>
> Interesting. This example implies that all packets are coming in
> through the same RX queue - is this right?
> If yes that's worth exploring - could be a tun bug -
> and shows how this patch is useful.
>
> > Signed-off-by: Sriram Narasimhan
>
> BTW, while you are looking at the stats, one other interesting
> thing to add could be checking more types of stats: number of exits,
> queue full errors, etc.
>
> > ---
> > drivers/net/virtio_net.c | 157
> > +-
> > 1 files changed, 128 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 3c23fdc..3c58c52 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -41,15 +41,46 @@ module_param(gso, bool, 0444);
> >
> > #define VIRTNET_DRIVER_VERSION "1.0.0"
> >
> > -struct virtnet_stats {
> > - struct u64_stats_sync tx_syncp;
> > +struct virtnet_rx_stats {
> > struct u64_stats_sync rx_syncp;
> > - u64 tx_bytes;
> > + u64 rx_packets;
> > + u64 rx_bytes;
> > +};
> > +
> > +struct virtnet_tx_stats {
> > + struct u64_stats_sync tx_syncp;
> > u64 tx_packets;
> > + u64 tx_bytes;
> > +};
> >
> > - u64 rx_bytes;
> > - u64 rx_packets;
>
> I think maintaining the stats in a per-queue data structure like this is
> fine. if # of CPUs == # of queues which is typical, we use same amount
> of memory. And each queue access is under a lock,
> or from napi thread, so no races either.
>
> > +struct virtnet_ethtool_stats {
> > + char desc[ETH_GSTRING_LEN];
> > + int type;
> > + int size;
> > + int offset;
> > +};
> > +
> > +enum {VIRTNET_STATS_TX, VIRTNET_STATS_RX};
> > +
> > +#define VIRTNET_RX_STATS_INFO(_struct, _field) \
> > + {#_field, VIRTNET_STATS_RX, FIELD_SIZEOF(_struct, _field), \
> > + offsetof(_struct, _field)}
> > +
> > +#define VIRTNET_TX_STATS_INFO(_struct, _field) \
> > + {#_field, VIRTNET_STATS_TX, FIELD_SIZEOF(_struct, _field), \
> > + offsetof(_struct, _field)}
> > +
> > +static const struct virtnet_ethtool_stats virtnet_et_rx_stats[] = {
> > + VIRTNET_RX_STATS_INFO(struct virtnet_rx_stats, rx_packets),
> > + VIRTNET_RX_STATS_INFO(struct virtnet_rx_stats, rx_bytes)
> > +};
> > +#define VIRTNET_RX_STATS_NUM (ARRAY_SIZE(virtnet_et_rx_stats))
> > +
> > +static const struct virtnet_ethtool_stats virtnet_et_tx_stats[] = {
> > + VIRTNET_TX_STATS_INFO(struct virtnet_tx_stats, tx_packets),
> > + VIRTNET_TX_STATS_INFO(struct
Re: [PATCH 1/1] 6lowpan: Fix fragmentation with link-local compressed addresses
Hi David, can you use a link-layer address on the current net-next kernel? I am asking because I can't use a link-layer address currently. Your patch doesn't help to solve my problem with link-layer addresses. To your patch: We get the link-layer addresses from skb not from the allocated frame->skb. Here is the code: _saddr = mac_cb(skb)->sa.hwaddr; _daddr = mac_cb(skb)->da.hwaddr; Here is skb != frame->skb so we don't need to copy it to frame->skb->cb because we already the link-layer addresses from skb->cb. Is there another place in the code where we get the link-layer addresses from allocated "frame" structure? Regards Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCHv3 3/6] clk: Add TI-Nspire clock drivers
On Sunday 19 May 2013, Daniel Tang wrote: > If the vendors for the on-SOC components are unknown, should we just > leave the compatible strings as is (i.e. "nspire-XXX")? In that case, I would use the name of the company that made the SoC. I believe someone mentioned it was made by LSI logic. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3.9.3
I'm announcing the release of the 3.9.3 kernel. All users of the 3.9 kernel series must upgrade. The updated 3.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/include/asm/cmpxchg.h |8 - arch/arm/mach-exynos/include/mach/regs-pmu.h |1 arch/arm/mach-exynos/pmu.c |5 arch/arm/mach-omap2/board-rx51-peripherals.c |4 arch/parisc/Makefile | 23 +-- arch/parisc/kernel/entry.S | 172 ++- arch/powerpc/include/asm/rtas.h |2 arch/powerpc/kernel/machine_kexec_64.c |4 arch/powerpc/kernel/rtas.c | 113 + arch/powerpc/platforms/pseries/suspend.c | 22 +++ arch/tile/Kconfig| 14 +- arch/tile/include/hv/hypervisor.h| 27 +++- arch/tile/kernel/head_32.S |2 arch/tile/kernel/head_64.S | 12 + arch/x86/Kconfig |1 arch/x86/kernel/microcode_intel_early.c |5 arch/x86/kvm/emulate.c | 42 ++ arch/x86/kvm/vmx.c |6 arch/x86/xen/enlighten.c | 15 ++ drivers/acpi/acpica/exfldio.c| 14 ++ drivers/acpi/ec.c|4 drivers/block/drbd/drbd_main.c |1 drivers/block/drbd/drbd_receiver.c |5 drivers/char/ipmi/ipmi_bt_sm.c |4 drivers/char/ipmi/ipmi_devintf.c | 14 ++ drivers/cpufreq/intel_pstate.c | 67 ++ drivers/dma/of-dma.c |8 - drivers/dma/pch_dma.c|2 drivers/gpu/drm/drm_crtc.c |4 drivers/gpu/drm/drm_mm.c | 34 ++--- drivers/gpu/drm/i915/intel_fb.c | 16 ++ drivers/gpu/drm/mgag200/mgag200_mode.c | 69 +++--- drivers/gpu/drm/radeon/r300_cmdbuf.c |2 drivers/gpu/drm/radeon/radeon_drv.c | 12 + drivers/hid/hid-core.c |1 drivers/md/dm-bufio.c| 24 +++ drivers/md/dm-cache-target.c |1 drivers/md/dm-snap.c |1 drivers/md/dm-stripe.c | 11 - drivers/md/dm-table.c|2 drivers/net/ethernet/3com/3c509.c|2 drivers/net/ethernet/3com/3c59x.c| 27 ++-- drivers/net/ethernet/sfc/mcdi.c |2 drivers/net/ethernet/tile/tilegx.c |2 drivers/net/macvlan.c|7 - drivers/net/tun.c|7 - drivers/net/usb/asix_common.c|3 drivers/net/wireless/ath/ath9k/main.c|6 drivers/net/wireless/b43/dma.c | 19 ++ drivers/net/wireless/b43/dma.h |4 drivers/net/wireless/b43/main.c | 43 ++ drivers/net/wireless/iwlegacy/4965-mac.c |3 drivers/net/wireless/mwifiex/cfg80211.c |3 drivers/net/wireless/mwifiex/cmdevt.c|1 drivers/net/wireless/mwifiex/main.c |1 drivers/net/wireless/mwifiex/sta_ioctl.c | 21 --- drivers/platform/x86/hp_accel.c |3 drivers/rtc/Kconfig |2 drivers/rtc/rtc-pcf2123.c|1 drivers/scsi/sd.c| 20 +++ drivers/scsi/sd.h|1 drivers/target/iscsi/iscsi_target_erl1.c |7 - drivers/target/target_core_file.c| 10 - drivers/target/target_core_iblock.c |2 drivers/target/target_core_transport.c | 11 - drivers/watchdog/watchdog_dev.c |3 fs/ext4/mballoc.c|6 fs/namei.c |2 fs/nfsd/nfs4proc.c | 15 ++ fs/nfsd/nfs4recover.c| 12 - include/linux/audit.h|7 - include/linux/kref.h | 33 + include/linux/time.h |4 include/net/inet_frag.h |5 include/net/sock.h | 12 + include/net/tcp.h|1 include/uapi/linux/audit.h |1 include/uapi/linux/if_cablemodem.h | 12 - include/uapi/linux/virtio_net.h |2 ipc/shm.c|8 + kernel/auditfilter.c | 31
[git pull] device-mapper fix for 3.10
Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm tags/dm-3.10-fixes to get the following device-mapper fix for 3.10. Thanks, Alasdair A patch to fix metadata resizing with device-mapper thin devices. Alasdair G Kergon (1): dm thin: fix metadata dev resize detection drivers/md/dm-thin.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 net-next 0/4] net: low latency Ethernet device polling
On 19/05/2013 22:06, Or Gerlitz wrote: Last time you've placed a copy of the patchset in the rfc branch of git://github.com/jbrandeb/lls.git - can you repost there V2 too? Or. BTW did you try the last version on your HW? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 net-next 0/4] net: low latency Ethernet device polling
On 19/05/2013 22:06, Or Gerlitz wrote: On Sun, May 19, 2013 at 1:25 PM, Eliezer Tamir wrote: This is an updated version of the code we posted on February. Last time you've placed a copy of the patchset in the rfc branch of git://github.com/jbrandeb/lls.git - can you repost there V2 too? Or. Yes, but it will have to wait for tomorrow. It's on Jesse's github account and for him it's still the middle of the weekend. -Eliezer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 net-next 0/4] net: low latency Ethernet device polling
On Sun, May 19, 2013 at 1:25 PM, Eliezer Tamir wrote: > This is an updated version of the code we posted on February. Last time you've placed a copy of the patchset in the rfc branch of git://github.com/jbrandeb/lls.git - can you repost there V2 too? Or. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] drivers: net: usb: rtl8150: bug fixing and cleanup
Petko Manolov : > On Sat, 18 May 2013, Francois Romieu wrote: > > > From: Petko Manolov [...] > > > Moving constant and structure definitions out of rtl8150.c; > > > > What's the point ? > > The general logic of having .h files applies. Which one ? - share it through the kernel or with userspace - personal choice .c split I don't mind the later even if it does not exactly apply to a WIP driver. I'd still avoid future copycat followers though. [...] > > > drivers/net/usb/rtl8150.c | 121 +-- > > > 1 file changed, 2 insertions(+), 119 deletions(-) > > > > > > diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c > > > index a491d3a..7d1897b 100644 > > > --- a/drivers/net/usb/rtl8150.c > > > +++ b/drivers/net/usb/rtl8150.c > > > @@ -17,132 +17,15 @@ > > > #include > > > #include > > > > > > +#include "rtl8150.h" > > > > It won't compile. You shouldn't do that. > > It does compile. Both inside and outside of the tree. The rtl8150.h file is created in patch #2. This is patch #1. So... -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] drivers: net: usb: rtl8150: bug fixing and cleanup
Petko Manolov : [...] > > > + usb_fill_control_urb(async_urb, dev->udev, > > > + usb_sndctrlpipe(dev->udev, 0), (void *) >dr, > > > > Useless void * cast. > > Wrong. The compiler actually moans quite a lot: > > /usr/src/git/rtl8150/rtl8150.c: In function ?async_set_registers?: > /usr/src/git/rtl8150/rtl8150.c:92:9: warning: passing argument 4 of > ?usb_fill_control_urb? from incompatible pointer type [enabled by default] > In file included from /usr/src/git/rtl8150/rtl8150.c:17:0: > include/linux/usb.h:1440:20: note: expected ?unsigned char *? but argument is > of type ?struct usb_ctrlrequest *? Sorry, I confused it with transfer_buffer. Some drivers go through unsigned char *, some widen it to void *. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory
Hi,
On 05/17/2013 01:26 PM, Viresh Kumar wrote:
> When we don't have any file in cpu/cpufreq directory we shouldn't create it.
> Specially with the introduction of per-policy governor instance patchset, even
> governors are moved to cpu/cpu*/cpufreq/governor-name directory and so this
> directory is just not required.
>
> Lets have it only when required.
>
> Signed-off-by: Viresh Kumar
> ---
[...]
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index e3d7112..2e18b3d 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -678,9 +678,6 @@ static struct attribute *default_attrs[] = {
> NULL
> };
>
> -struct kobject *cpufreq_global_kobject;
> -EXPORT_SYMBOL(cpufreq_global_kobject);
> -
> #define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
> #define to_attr(a) container_of(a, struct freq_attr, attr)
>
> @@ -751,6 +748,49 @@ static struct kobj_type ktype_cpufreq = {
> .release= cpufreq_sysfs_release,
> };
>
> +struct kobject *cpufreq_global_kobject;
> +EXPORT_SYMBOL(cpufreq_global_kobject);
> +
> +static int cpufreq_global_kobject_usage;
> +
> +int get_cpufreq_global_kobject(void)
> +{
> + if (!cpufreq_global_kobject_usage++)
> + return kobject_add(cpufreq_global_kobject,
> + _subsys.dev_root->kobj, "%s", "cpufreq");
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(get_cpufreq_global_kobject);
> +
> +void put_cpufreq_global_kobject(void)
> +{
> + if (!--cpufreq_global_kobject_usage)
> + kobject_del(cpufreq_global_kobject);
> +}
> +EXPORT_SYMBOL(put_cpufreq_global_kobject);
Global symbol names should begin with a sensible prefix; in this case,
it looks like cpufreq_get_global_kobject and cpufreq_put_global_kobject
would be more appropriate names.
Regards,
Francesco
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 000/102] 3.9.3-stable review
On Sun, May 19, 2013 at 10:00:55PM +0900, Satoru Takeuchi wrote: > At Fri, 17 May 2013 14:35:15 -0700, > Greg Kroah-Hartman wrote: > > > > This is the start of the stable review cycle for the 3.9.3 release. > > There are 102 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun May 19 21:30:33 UTC 2013. > > Anything received after that time might be too late. > > This kernel can be built and boot without any problem. > Building a kernel with this kernel also works fine. Thanks for testing. 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: [ 027/102] x86, vm86: fix VM86 syscalls: use SYSCALL_DEFINEx(...)
On Fri, May 17, 2013 at 04:51:33PM -0700, Greg Kroah-Hartman wrote: > On Fri, May 17, 2013 at 11:49:30PM +0100, Al Viro wrote: > > On Fri, May 17, 2013 at 02:35:42PM -0700, Greg Kroah-Hartman wrote: > > > 3.9-stable review patch. If anyone has any objections, please let me > > > know. > > > > This is seriously wrong. For 3.9 you _need_ asmlinkage_protect() in that > > thing; by the time when that went into the tree, mainline already had > > it generated automatically by SYSCALL_DEFINE, so there was no point in > > that part of patch - the switch to SYSCALL_DEFINE alone did the job. > > For 3.9 it's very much needed; as the matter of fact, in 3.9 that commit > > is a no-op in the form you took. > > > > We can grab all prereqs into 3.9-stable (there's not that much of those), > > but that would be much more intrusive than the variant adding explicit > > asmlinkage_protect() in those two syscalls. > > Ok, Alexander was saying something was off here. > > Can someone send me just the needed patch to get this working properly, > and I will be glad to drop this one from the 3.9.x tree. I've now dropped this, and will release without it. 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/
Linux 3.4.46
I'm announcing the release of the 3.4.46 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/mach-omap2/board-rx51-peripherals.c |4 arch/powerpc/include/asm/rtas.h |2 arch/powerpc/kernel/rtas.c | 113 +++ arch/powerpc/platforms/pseries/suspend.c | 22 + arch/x86/kvm/vmx.c |6 + arch/x86/xen/enlighten.c | 15 +++ drivers/acpi/acpica/exfldio.c| 14 +++ drivers/acpi/ec.c|4 drivers/block/drbd/drbd_receiver.c |1 drivers/char/ipmi/ipmi_bt_sm.c |4 drivers/char/ipmi/ipmi_devintf.c | 14 +++ drivers/dma/pch_dma.c|2 drivers/gpu/drm/drm_mm.c | 34 drivers/gpu/drm/radeon/r300_cmdbuf.c |2 drivers/md/dm-snap.c |1 drivers/md/dm-thin.c |2 drivers/net/ethernet/3com/3c509.c|2 drivers/net/ethernet/3com/3c59x.c| 27 +++--- drivers/net/ethernet/realtek/r8169.c | 14 +-- drivers/net/ethernet/sfc/mcdi.c |2 drivers/net/macvlan.c|7 - drivers/net/usb/qmi_wwan.c | 101 drivers/net/wireless/ath/ath9k/main.c|6 + drivers/net/wireless/b43/dma.c | 19 drivers/net/wireless/b43/dma.h |4 drivers/net/wireless/b43/main.c | 43 -- drivers/net/wireless/mwifiex/cmdevt.c|1 drivers/net/wireless/mwifiex/sta_ioctl.c | 21 + drivers/platform/x86/hp_accel.c |3 drivers/rtc/rtc-pcf2123.c|1 drivers/scsi/sd.c| 20 drivers/scsi/sd.h|1 drivers/target/iscsi/iscsi_target_erl1.c |7 - fs/ext4/mballoc.c|6 + fs/hugetlbfs/inode.c | 20 ++-- fs/nfsd/nfs4proc.c | 15 +++ include/linux/audit.h|2 include/linux/hugetlb.h |9 -- include/linux/if_cablemodem.h| 12 +- include/linux/rculist.h | 17 include/net/sock.h | 12 ++ include/net/tcp.h|1 ipc/shm.c|4 kernel/kmod.c|5 + kernel/time/tick-sched.c |2 kernel/timer.c |2 kernel/trace/trace_events_filter.c |4 mm/mmap.c|6 + net/8021q/vlan_dev.c |2 net/bridge/br_stp_timer.c|2 net/core/dev.c |2 net/core/ethtool.c |2 net/core/sock.c | 12 -- net/ipv6/tcp_ipv6.c | 12 ++ net/ipv6/udp.c | 13 ++- net/ipv6/udp_impl.h |2 net/ipv6/udplite.c |2 net/ipv6/xfrm6_policy.c |4 net/packet/af_packet.c | 54 net/sched/act_ipt.c | 33 +++ sound/pci/hda/hda_codec.c|3 sound/soc/codecs/wm8994.c|1 63 files changed, 596 insertions(+), 186 deletions(-) Aaro Koskinen (1): ARM: OMAP: RX-51: change probe order of touchscreen and panel SPI devices Anton Blanchard (1): audit: Syscall rules are not applied to existing processes on non-x86 Ben Hutchings (1): sfc: Fix naming of MTD partitions for FPGA bitfiles Benjamin LaHaise (1): ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex Bing Zhao (1): mwifiex: clear is_suspended flag when interrupt is received early Bjørn Mork (4): net: qmi_wwan: fixup missing ethernet header (firmware bug workaround) net: qmi_wwan: fixup destination address (firmware bug workaround) net: qmi_wwan: prevent duplicate mac address on link (firmware bug workaround) net: vlan,ethtool: netdev_features_t is more than 32 bit Bob Moore (1): ACPICA: Fix possible buffer overflow during a field unit read operation Chen Gang (1): drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow
Re: Linux 3.0.79
diff --git a/Makefile b/Makefile
index f111c5b..f8ade05 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 78
+SUBLEVEL = 79
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index c565971..9a1e1f7 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -56,11 +56,11 @@
#define RX51_USB_TRANSCEIVER_RST_GPIO 67
-/* list all spi devices here */
+/* List all SPI devices here. Note that the list/probe order seems to matter!
*/
enum {
RX51_SPI_WL1251,
- RX51_SPI_MIPID, /* LCD panel */
RX51_SPI_TSC2005, /* Touch Controller */
+ RX51_SPI_MIPID, /* LCD panel */
};
static struct wl12xx_platform_data wl1251_pdata;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 2ad060a..be1d830 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3836,6 +3836,12 @@ static int handle_invalid_guest_state(struct kvm_vcpu
*vcpu)
if (err != EMULATE_DONE)
return 0;
+ if (vcpu->arch.halt_request) {
+ vcpu->arch.halt_request = 0;
+ ret = kvm_emulate_halt(vcpu);
+ goto out;
+ }
+
if (signal_pending(current))
goto out;
if (need_resched())
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 063ce1f..e11efbd 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -129,6 +129,21 @@ static void xen_vcpu_setup(int cpu)
BUG_ON(HYPERVISOR_shared_info == _dummy_shared_info);
+ /*
+* This path is called twice on PVHVM - first during bootup via
+* smp_init -> xen_hvm_cpu_notify, and then if the VCPU is being
+* hotplugged: cpu_up -> xen_hvm_cpu_notify.
+* As we can only do the VCPUOP_register_vcpu_info once lets
+* not over-write its result.
+*
+* For PV it is called during restore (xen_vcpu_restore) and bootup
+* (xen_setup_vcpu_info_placement). The hotplug mechanism does not
+* use this function.
+*/
+ if (xen_hvm_domain()) {
+ if (per_cpu(xen_vcpu, cpu) == _cpu(xen_vcpu_info, cpu))
+ return;
+ }
if (cpu < MAX_VIRT_CPUS)
per_cpu(xen_vcpu,cpu) = _shared_info->vcpu_info[cpu];
diff --git a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c
index f915a7f..b334f54 100644
--- a/drivers/acpi/acpica/exfldio.c
+++ b/drivers/acpi/acpica/exfldio.c
@@ -702,7 +702,19 @@ acpi_ex_extract_from_field(union acpi_operand_object
*obj_desc,
if ((obj_desc->common_field.start_field_bit_offset == 0) &&
(obj_desc->common_field.bit_length == access_bit_width)) {
- status = acpi_ex_field_datum_io(obj_desc, 0, buffer, ACPI_READ);
+ if (buffer_length >= sizeof(u64)) {
+ status =
+ acpi_ex_field_datum_io(obj_desc, 0, buffer,
+ ACPI_READ);
+ } else {
+ /* Use raw_datum (u64) to handle buffers < 64 bits */
+
+ status =
+ acpi_ex_field_datum_io(obj_desc, 0, _datum,
+ ACPI_READ);
+ ACPI_MEMCPY(buffer, _datum, buffer_length);
+ }
+
return_ACPI_STATUS(status);
}
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index d2519b2..51de186 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -217,7 +217,7 @@ static int ec_check_sci_sync(struct acpi_ec *ec, u8 state)
static int ec_poll(struct acpi_ec *ec)
{
unsigned long flags;
- int repeat = 2; /* number of command restarts */
+ int repeat = 5; /* number of command restarts */
while (repeat--) {
unsigned long delay = jiffies +
msecs_to_jiffies(ec_delay);
@@ -235,8 +235,6 @@ static int ec_poll(struct acpi_ec *ec)
}
advance_transaction(ec, acpi_ec_read_status(ec));
} while (time_before(jiffies, delay));
- if (acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF)
- break;
pr_debug(PREFIX "controller reset, restart transaction\n");
spin_lock_irqsave(>curr_lock, flags);
start_transaction(ec);
diff --git a/drivers/block/drbd/drbd_receiver.c
b/drivers/block/drbd/drbd_receiver.c
index 43beaca..13cbdd3 100644
--- a/drivers/block/drbd/drbd_receiver.c
+++ b/drivers/block/drbd/drbd_receiver.c
@@ -2225,7 +2225,6 @@ static int drbd_asb_recover_1p(struct drbd_conf *mdev)
__must_hold(local)
if (hg == -1 &&
Linux 3.0.79
I'm announcing the release of the 3.0.79 kernel. All users of the 3.0 kernel series must upgrade. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 - arch/arm/mach-omap2/board-rx51-peripherals.c |4 +-- arch/x86/kvm/vmx.c |6 arch/x86/xen/enlighten.c | 15 +++ drivers/acpi/acpica/exfldio.c| 14 ++- drivers/acpi/ec.c|4 --- drivers/block/drbd/drbd_receiver.c |1 drivers/char/ipmi/ipmi_bt_sm.c |4 +-- drivers/char/ipmi/ipmi_devintf.c | 14 ++- drivers/dma/pch_dma.c|2 - drivers/gpu/drm/drm_mm.c | 34 ++- drivers/gpu/drm/radeon/r300_cmdbuf.c |2 - drivers/md/dm-snap.c |1 drivers/net/3c509.c |2 + drivers/net/3c59x.c | 27 +++-- drivers/net/macvlan.c|7 +++-- drivers/net/r8169.c | 13 -- drivers/net/wireless/ath/ath9k/main.c|6 +++- drivers/net/wireless/mwifiex/cmdevt.c|1 drivers/net/wireless/mwifiex/sta_ioctl.c | 21 drivers/rtc/rtc-pcf2123.c|1 drivers/scsi/sd.c| 20 +++ drivers/scsi/sd.h|1 fs/ext4/mballoc.c|6 +++- include/linux/if_cablemodem.h| 12 - include/linux/rculist.h | 17 + include/net/sock.h | 12 + include/net/tcp.h|1 kernel/kmod.c|5 +++ kernel/time/tick-sched.c |2 - kernel/timer.c |2 - net/bridge/br_stp_timer.c|2 - net/core/sock.c | 12 - net/ipv6/tcp_ipv6.c | 12 + net/ipv6/udp.c | 13 +- net/ipv6/udp_impl.h |2 + net/ipv6/udplite.c |2 - net/ipv6/xfrm6_policy.c |4 ++- net/sched/act_ipt.c | 33 +++--- sound/soc/codecs/wm8994.c|1 40 files changed, 244 insertions(+), 96 deletions(-) Aaro Koskinen (1): ARM: OMAP: RX-51: change probe order of touchscreen and panel SPI devices Benjamin LaHaise (1): ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex Bing Zhao (1): mwifiex: clear is_suspended flag when interrupt is received early Bob Moore (1): ACPICA: Fix possible buffer overflow during a field unit read operation Chen Gang (1): drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow Cong Wang (1): xfrm6: release dev before returning error Dan Carpenter (1): ASoC: wm8994: missing break in wm8994_aif3_hw_params() Daniel Drake (1): mwifiex: fix setting of multicast filter Daniel Vetter (1): drm/mm: fix dump table BUG Eric Dumazet (2): tcp: force a dst refcount when prequeue packet ipv6: do not clear pinet6 field Felix Fietkau (1): ath9k: fix key allocation error handling for powersave keys Francois Romieu (1): r8169: fix vlan tag read ordering. Gleb Natapov (1): KVM: VMX: fix halt emulation while emulating invalid guest sate Greg Kroah-Hartman (1): Linux 3.0.79 Jamal Hadi Salim (1): net_sched: act_ipt forward compat with xtables James Bottomley (1): SCSI: sd: fix array cache flushing bug causing performance problems Jiri Pirko (1): macvlan: fix passthru mode race between dev removal and rx path Josh Boyer (1): if_cablemodem.h: Add parenthesis around ioctl macros Kees Cook (1): drm/radeon: check incoming cliprects pointer Konrad Rzeszutek Wilk (1): xen/vcpu/pvhvm: Fix vcpu hotplugging hanging. Lachlan McIlroy (1): ext4: limit group search loop for non-extent files Lan Tianyu (1): ACPI / EC: Restart transaction even when the IBF flag set Matthew Whitehead (1): 3c509.c: call SET_NETDEV_DEV for all device types (ISA/ISAPnP/EISA) Oleg Nesterov (1): usermodehelper: check subprocess_info->path != NULL Philipp Reisner (1): drbd: fix for deadlock when using automatic split-brain-recovery Sergei Shtylyov (2): 3c59x: fix freeing nonexistent resource on driver
Re: [patch] gru: fix a sanity test in gru_set_context_option()
On Sun, May 19, 2013 at 09:44:42AM -0500, Dimitri Sivanich wrote:
>
> Since we're here, maybe we should neaten this up a little?
>
> Signed-off-by: Dimitri Sivanich
> ---
> drivers/misc/sgi-gru/grufault.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> Index: linux/drivers/misc/sgi-gru/grufault.c
> ===
> --- linux.orig/drivers/misc/sgi-gru/grufault.c
> +++ linux/drivers/misc/sgi-gru/grufault.c
> @@ -876,8 +876,9 @@ int gru_set_context_option(unsigned long
> switch (req.op) {
> case sco_blade_chiplet:
> /* Select blade/chiplet for GRU context */
> - if (req.val1 < -1 || req.val1 >= GRU_MAX_BLADES ||
> !gru_base[req.val1] ||
> - req.val0 < -1 || req.val0 >= GRU_CHIPLETS_PER_HUB) {
> + if (req.val0 < -1 || req.val0 >= GRU_CHIPLETS_PER_HUB ||
> + req.val1 < -1 || req.val1 >= GRU_MAX_BLADES ||
> + (req.val1 >= 0 && !gru_base[req.val1])) {
> ret = -EINVAL;
I generally prefer how in the original code all the sub conditions
were aligned nicely but I will Ack your version as well. Thanks.
regards,
dan carpenter
> } else {
> gts->ts_user_blade_id = req.val1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] 6lowpan: Fix fragmentation with link-local compressed addresses
When a new 6lowpan fragment is received, a skbuff is allocated for the reassembled packet. However when a 6lowpan packet compresses link-local addresses based on link-layer addresses, the processing function relies on the skb mac control block to find the related link-layer address. This patch copies the control block from the first fragment into the newly allocated skb to keep a trace of the link-layer addresses in case of a link-local compressed address. Signed-off-by: David Hauweele --- net/ieee802154/6lowpan.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index 55e1fd5..d9a41e2 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -702,6 +702,13 @@ lowpan_alloc_new_frame(struct sk_buff *skb, u16 len, u16 tag) skb_reserve(frame->skb, sizeof(struct ipv6hdr)); skb_put(frame->skb, frame->length); + /* +* copy the first control block to keep a +* trace of the link-layer addresses in case +* of a link-local compressed address +*/ + memcpy(frame->skb->cb, skb->cb, sizeof(skb->cb)); + init_timer(>timer); /* time out is the same as for ipv6 - 60 sec */ frame->timer.expires = jiffies + LOWPAN_FRAG_TIMEOUT; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] do_execve_common: use current_user()
Trivial cleanup. do_execve_common() can use current_user() and
avoid the unnecessary "struct cred *cred" var.
Signed-off-by: Oleg Nesterov
---
fs/exec.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 6430195..13f9bb0 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1461,7 +1461,6 @@ static int do_execve_common(const char *filename,
struct files_struct *displaced;
bool clear_in_exec;
int retval;
- const struct cred *cred = current_cred();
/*
* We move the actual failure in case of RLIMIT_NPROC excess from
@@ -1470,7 +1469,7 @@ static int do_execve_common(const char *filename,
* whether NPROC limit is still exceeded.
*/
if ((current->flags & PF_NPROC_EXCEEDED) &&
- atomic_read(>user->processes) > rlimit(RLIMIT_NPROC)) {
+ atomic_read(_user()->processes) > rlimit(RLIMIT_NPROC)) {
retval = -EAGAIN;
goto out_ret;
}
--
1.5.5.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: Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels
On Sun, May 19, 2013 at 8:34 AM, luke.leighton wrote: > On Sun, May 19, 2013 at 12:19 PM, Jonas Gorski > wrote: > that doesn't sound right. actually, this is a very very important > misunderstanding, jonas. > > you *can* choose GPLv3 code. what you can choose is: *only* those > files of the linux kernel that are released under GPLv3. No,, you can't. The second you do, you cannot use the GPLv2 code with it *AT ALL*, making the code you chose to use for the GPLv3 worthless when used in conjunction with the kernel itself. As such, when you say, "I'm accepting the GPLv3 for this file", you need to now immediately take that file, move it OUT of the kernel source tree, and use it for whatever you like, but not under the Linux kernel, making it, for the most part, worthless to you unless you are writing your own software. > many people point out that just because this is unlikely to result in > success any time in the next 100 years, that nobody should bother even > starting. Go house, but make sure to delete any GPLv2 code. I suspect you'll find you'll have a really hard time, as you won't have a kernel. >> So any further licenses will never apply to any use in the kernel. > > incorrect!! logical assertion error!! :) > assert(ELOGICALCONCLUSIONBRAINFART) You go house, as your one guy making assertions on the Linux kernel which has been supported and under active development for over 21 years now. >> Only if somebody took your code out of the kernel and used it in a >> separate GPLv3+ project, then the GPLv3+ license could and would >> apply. > > after reviewing the above pseudo-code i believe you'll agree that > that's slightly misleading. one could also choose to leave the files > in-place in the *same* project's source tree, and just not use any of > the ones that were incompatibly-licensed. Correct, except that the kernel, the thing that actually *IS* the software, won't exist in your tree any longer. Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/50] 3.4.46-stable review
On Sun, May 19, 2013 at 08:16:14PM +0900, Satoru Takeuchi wrote: > At Fri, 17 May 2013 14:46:35 -0700, > Greg Kroah-Hartman wrote: > > > > This is the start of the stable review cycle for the 3.4.46 release. > > There are 50 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun May 19 21:37:09 UTC 2013. > > Anything received after that time might be too late. > > This kernel can be built and boot without any problem. > Building a kernel with this kernel also works fine. Thanks for testing. 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: Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels
On Sun, May 19, 2013 at 8:24 AM, luke.leighton wrote: > it does in some ways. it doesn't answer the specific question, "how > do i formally get my copyright announcement updated in the linux > kernel source code" yet though but it does provide some opportunity to > point out some errors and mis-... mis-somethings, i can't think of the > exact word. You submit a patch which will be peer reviewed, and will be rejected I suspect. > interesting. this statement completely and utterly misses the point. > it assumes that "the kernel" and "the license" are directly and > irrevocably linked. which they most certainly are not. ... Yes they are. You only have the code due to the license, and once licences, the license cannot be terminated (the irrevocable part) > which, again is mis-leading - in this case very very badly - because > it implies that somehow just because *most* of the files are under one > license, therefore automatically people should not make their *own* > mind - their own free and conscious choice - to release their > contributions under alternative licenses. Do you have ANY idea what your talking about? As this point, it seems like your just making stuff up for the sake of the argument. > "we the major linux copyright holders, who wrote this documentation, > respect your decision to choose an additional license as well as the > GPLv2 to release your code under, and it is important to make it clear > that we do not seek to influence your right to choose an additional > license or licenses, one way or the other. the key to remember is > that any files released under licenses *not* compatible with the GPLv2 > *CANNOT* legally be used. > as the kernel is an aggregated work, over > time the accumulation of files under alternative licenses (those that > are compatible with the current GPLv2 license) *may* result in a > useful and useable subset of the linux kernel source files coming > about. so our personal opinion here - which should in no way > influence your own decisions - is that you are pissing in the wind if > you think that's going to come about any time soon, and as a result of > that, we (the major linux copyright holders who wrote this > documentation) decided not to bother releasing our contributions under > any license other than the GPLv2." Nothing stops anyone from releasing their files all by themselves under whatever license they choose. However incompatible dual licenses would end up not being accepted, and not becoming part of Linux. Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels
On Sun, May 19, 2013 at 6:39 AM, luke.leighton wrote: > mr linus torvalds is one person. he is not a god. he does not > dictate that which everyone else can choose to do. if mr linus > torvalds is telling everyone "he will not use the GPLv3 for the > kernel" i.e. NOBODY may dual-license their copyright material in the > linux kernel then he is *MASSIVELY* overstepping a serious boundary of > both propriety and copyright law. if i choose to release all > copyright code under dual licenses then THAT IS MY RIGHT AND NO FUCKER > IS GOING TO TELL ME OTHERWISE. Well that's all well and good, but you couldn't place GPLv3 code into the kernel, s. There's not much point in dual licensing it when it could never be utilized in that manner. > so, let's nip this in the bud and set it straight, ok? > > i assume that what mr linus torvalds *meant* to say was "i have some > code, it is under my copyright. i personally choose not to release > that copyright material under any license other than the GPLv2 and > that is my choice and my right as the owner of that copyright > material. signed, mr linus torvalds". And gplv3 code would be incompatible with the license, so, no, you couldn't add code to the Linux kernel under the GPLv3. Write a new kernel, and go house I suppose. > that choice - made by mr linus torvalds - has *nothing to do with > anybody else's choice*. Except, the Linux kernel is the code we're talking about here. So yes, their choices on what to do with his code (and many others code) DOES has something to do with the original authors choice. > so the question remains, and i'd like an answer: what is the > procedure for formally adding to the linux kernel that my copyrighted > material is dual-licensed under both the GPLv2 and the GPLv3+? do i > submit a patch, and is it as simple as that? You submit a patch, it is reviewed, and may or may not be included. And with the GPLv3 provision, it will not be accepted. > unless unless what mr linus torvalds meant to say was, "i don't > like the GPLv3+ license. if any fucker wants to release linux kernel > code under the GPLv3+ (as well as the GPLv2), they can fuck off. in > fact, they will be banned from submitting contributions that are not > specifically GPLv2. if they try to dual-license their code, it will > not be accepted. i, linus torvalds, have spoken". which i seriously > seriously doubt, but there seems to be some implication that that's > the case, here. Soo, you don't want your code in his kernel then, do you. > well, it will continue to be "allowed" for many many years, even if > people dual-license their code in the linux kernel. *sigh* Point to a single line of GPLv3 code in the current kernel. -- -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
