Re: [PATCH] ext4: explain encoding of 34-bit a,c,mtime values
On Sat, 2013-11-09 at 15:51 -0800, Mark Harris wrote: > > The problem with the existing encoding is that pre-1970 dates are > encoded with extra bits 1,1 in 64-bit kernels with ext4, but on 32-bit > kernels and inodes that were originally written as ext3 the extra bits > will be 0,0. Currently, both are decoded as pre-1970 dates. > > With your patch, only the 1,1 format used by 64-bit ext4 will decode > as a pre-1970 date. Dates previously written by ext3 or a 32-bit > kernel will no longer be decoded as expected. Also the patch does > not update ext4_encode_extra_time to use this format for pre-1970 > dates in 32-bit mode. You're right -- I missed the complexity here. > Possible solutions were discussed here, but no decision was made: > http://thread.gmane.org/gmane.comp.file-systems.ext4/26087/focus=26406 To summarize, the previous discussion offered four possible solutions, of which two were thought good: b. Use Andreas's encoding, which is incompatible with pre-1970 files written on 64-bit systems. c. Use an encoding which is compatible with all pre-1970 files, but incompatible with 64-bit post-2038 files, and which encodes a smaller range of time and is more complicated. --- I don't care about currently-existing post-2038 files, because I believe that nobody has a valid reason to have such files. However, I do believe that pre-1970 files are probably important to someone. Despite this, I prefer option (b), because I think the simplicity is valuable, and because I hate to give up date ranges (even ones that I think we'll "never" need). Option (b) is not actually lossy, because we could correct pre-1970 files with e2fsck; under Andreas's encoding, their dates would be in the far future (and thus cannot be legitimate). Would a patch that does (b) be accepted? I would accompany it with a patch to e2fsck (which I assume would also go to the ext4 developers mailing list?). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 1/4] dma: imx-sdma: Add sdma firmware version 2 support
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Nicolin
> Chen
> Sent: Friday, November 08, 2013 4:20 PM
> To: vinod.k...@intel.com; dan.j.willi...@intel.com; s.ha...@pengutronix.de;
> ti...@tabi.org; shawn@linaro.org; broo...@kernel.org
> Cc: mark.rutl...@arm.com; devicet...@vger.kernel.org; alsa-devel@alsa-
> project.org; pawel.m...@arm.com; linux-...@vger.kernel.org;
> swar...@wwwdotorg.org; linux-kernel@vger.kernel.org; rob.herr...@calxeda.com;
> dmaeng...@vger.kernel.org; ijc+devicet...@hellion.org.uk; linuxppc-
> d...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> Subject: [PATCH v4 1/4] dma: imx-sdma: Add sdma firmware version 2 support
>
> On i.MX5/6 series, SDMA is using new version firmware to support SSI dual FIFO
> feature and HDMI Audio (i.MX6Q/DL only). Thus add it.
>
> Signed-off-by: Nicolin Chen
> ---
> drivers/dma/imx-sdma.c | 15 ++-
> include/linux/platform_data/dma-imx-sdma.h | 5 +
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
> fc43603..c7ece8d 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -323,6 +323,7 @@ struct sdma_engine {
> struct clk *clk_ipg;
> struct clk *clk_ahb;
> spinlock_t channel_0_lock;
> + u32 script_number;
> struct sdma_script_start_addrs *script_addrs;
> const struct sdma_driver_data *drvdata;
> };
> @@ -1238,6 +1239,7 @@ static void sdma_issue_pending(struct dma_chan *chan) }
>
> #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1 34
> +#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2 38
>
> static void sdma_add_scripts(struct sdma_engine *sdma,
> const struct sdma_script_start_addrs *addr) @@ -1246,7 +1248,7
> @@
> static void sdma_add_scripts(struct sdma_engine *sdma,
> s32 *saddr_arr = (u32 *)sdma->script_addrs;
> int i;
>
> - for (i = 0; i < SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1; i++)
> + for (i = 0; i < sdma->script_number; i++)
> if (addr_arr[i] > 0)
> saddr_arr[i] = addr_arr[i];
> }
> @@ -1272,6 +1274,17 @@ static void sdma_load_firmware(const struct firmware
> *fw,
> void *context)
> goto err_firmware;
> if (header->ram_code_start + header->ram_code_size > fw->size)
> goto err_firmware;
> + switch (header->version_major) {
> + case 1:
> + sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1;
> + break;
> + case 2:
> + sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2;
> + break;
> + default:
> + dev_err(sdma->dev, "unknown firmware version\n");
> + return;
Why return and not "goto err_firmware" ?
-Bharat
> + }
>
> addr = (void *)header + header->script_addrs_start;
> ram_code = (void *)header + header->ram_code_start; diff --git
> a/include/linux/platform_data/dma-imx-sdma.h
> b/include/linux/platform_data/dma-
> imx-sdma.h
> index 3a39428..eabac4e 100644
> --- a/include/linux/platform_data/dma-imx-sdma.h
> +++ b/include/linux/platform_data/dma-imx-sdma.h
> @@ -43,6 +43,11 @@ struct sdma_script_start_addrs {
> s32 dptc_dvfs_addr;
> s32 utra_addr;
> s32 ram_code_start_addr;
> + /* End of v1 array */
> + s32 mcu_2_ssish_addr;
> + s32 ssish_2_mcu_addr;
> + s32 hdmi_dma_addr;
> + /* End of v2 array */
> };
>
> /**
> --
> 1.8.4
>
>
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ELAN Touchscreen regression in recent 3.12 rc's? (USB)
Well, that was fun. ;) git bisect start # bad: [69c88dc7d9f1a6c3eceb7058111677c640811c94] vfs: fix new kernel-doc warnings git bisect bad 69c88dc7d9f1a6c3eceb7058111677c640811c94 # good: [31d141e3a666269a3b6fcccddb0351caf7454240] Linux 3.12-rc6 git bisect good 31d141e3a666269a3b6fcccddb0351caf7454240 # good: [b403b73c21fcab11411a1439867a3ead9117e5e4] Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux git bisect good b403b73c21fcab11411a1439867a3ead9117e5e4 # good: [d55f0691c041dba46daad7790b8f2631acb55f9a] Merge remote-tracking branch 'asoc/fix/pcm1792a' into asoc-linus git bisect good d55f0691c041dba46daad7790b8f2631acb55f9a # good: [20c87bd40e6c1ff7e31cc5eea4fb37829a57eb58] Merge tag 'asoc-v3.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus git bisect good 20c87bd40e6c1ff7e31cc5eea4fb37829a57eb58 # good: [d24fec3991076124e069c889c530cdc69cd43fb8] Merge tag 'jfs-3.12' of git://github.com/kleikamp/linux-shaggy git bisect good d24fec3991076124e069c889c530cdc69cd43fb8 # good: [93cd00043fffec840fa36909c4a8eb0f735dfb04] Merge tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect good 93cd00043fffec840fa36909c4a8eb0f735dfb04 # good: [606d6fe3ffdb5190d4c8e4d6cd23aa6c1f9cb6ad] fs/namei.c: fix new kernel-doc warning git bisect good 606d6fe3ffdb5190d4c8e4d6cd23aa6c1f9cb6ad # first bad commit: [69c88dc7d9f1a6c3eceb7058111677c640811c94] vfs: fix new kernel-doc warnings Which is... nonsense. ;) So, I tried the first bad commit again and it works. After a small period of head scratching, I noticed that the other change in the non working kernel was re-enabling debugging options. So, I rebuild locally the bad kernel with the debugging config and sure enough it's back. So, it's some debugging option causing it. I can try and bisect again with debugging config but I just got this laptop recently, so it could be that all debugging kernels have the issue and it's nothing recent? The diff of configs is attached in case anything leaps out at people: kevin -- 164c164 < CONFIG_DEBUG_BLK_CGROUP=y --- > # CONFIG_DEBUG_BLK_CGROUP is not set 211d210 < CONFIG_PERF_USE_VMALLOC=y 217c216 < CONFIG_DEBUG_PERF_USE_VMALLOC=y --- > # CONFIG_DEBUG_PERF_USE_VMALLOC is not set 286c285 < CONFIG_MODULE_FORCE_UNLOAD=y --- > # CONFIG_MODULE_FORCE_UNLOAD is not set 346c345,350 < CONFIG_UNINLINE_SPIN_UNLOCK=y --- > CONFIG_INLINE_SPIN_UNLOCK_IRQ=y > CONFIG_INLINE_READ_UNLOCK=y > CONFIG_INLINE_READ_UNLOCK_IRQ=y > CONFIG_INLINE_WRITE_UNLOCK=y > CONFIG_INLINE_WRITE_UNLOCK_IRQ=y > CONFIG_MUTEX_SPIN_ON_OWNER=y 402,403c406,407 < CONFIG_MAXSMP=y < CONFIG_NR_CPUS=4096 --- > # CONFIG_MAXSMP is not set > CONFIG_NR_CPUS=128 409d412 < CONFIG_PREEMPT_COUNT=y 437c440 < CONFIG_NODES_SHIFT=10 --- > CONFIG_NODES_SHIFT=9 460c463 < CONFIG_SPLIT_PTLOCK_CPUS=99 --- > CONFIG_SPLIT_PTLOCK_CPUS=4 484c487 < CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y --- > # CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set 535c538 < CONFIG_PM_TEST_SUSPEND=y --- > # CONFIG_PM_TEST_SUSPEND is not set 561c564 < CONFIG_ACPI_DEBUG=y --- > # CONFIG_ACPI_DEBUG is not set 1391c1394 < CONFIG_CEPH_LIB_PRETTYDEBUG=y --- > # CONFIG_CEPH_LIB_PRETTYDEBUG is not set 1545c1548 < CONFIG_DRBD_FAULT_INJECTION=y --- > # CONFIG_DRBD_FAULT_INJECTION is not set 2293c2296 < CONFIG_ATH_DEBUG=y --- > # CONFIG_ATH_DEBUG is not set 2311c2314 < CONFIG_CARL9170_DEBUGFS=y --- > # CONFIG_CARL9170_DEBUGFS is not set 2342c2345 < CONFIG_B43_DEBUG=y --- > # CONFIG_B43_DEBUG is not set 2348c2351 < CONFIG_B43LEGACY_DEBUG=y --- > # CONFIG_B43LEGACY_DEBUG is not set 2384c2387 < CONFIG_IWLWIFI_DEVICE_TRACING=y --- > # CONFIG_IWLWIFI_DEVICE_TRACING is not set 4745,4746c4748 < CONFIG_DMADEVICES_DEBUG=y < CONFIG_DMADEVICES_VDEBUG=y --- > # CONFIG_DMADEVICES_DEBUG is not set 5202c5204 < CONFIG_EXT4_DEBUG=y --- > # CONFIG_EXT4_DEBUG is not set 5204c5206 < CONFIG_JBD2_DEBUG=y --- > # CONFIG_JBD2_DEBUG is not set 5249c5251 < CONFIG_QUOTA_DEBUG=y --- > # CONFIG_QUOTA_DEBUG is not set 5380c5382 < CONFIG_NFSD_FAULT_INJECTION=y --- > # CONFIG_NFSD_FAULT_INJECTION is not set 5505c5507 < CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y --- > # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set 5513,5521c5515,5516 < CONFIG_DEBUG_OBJECTS=y < # CONFIG_DEBUG_OBJECTS_SELFTEST is not set < CONFIG_DEBUG_OBJECTS_FREE=y < CONFIG_DEBUG_OBJECTS_TIMERS=y < CONFIG_DEBUG_OBJECTS_WORK=y < CONFIG_DEBUG_OBJECTS_RCU_HEAD=y < CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y < CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1 < CONFIG_SLUB_DEBUG_ON=y --- > # CONFIG_DEBUG_OBJECTS is not set > # CONFIG_SLUB_DEBUG_ON is not set 5524,5528c5519,5520 < CONFIG_DEBUG_KMEMLEAK=y < CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=1024 < # CONFIG_DEBUG_KMEMLEAK_TEST is not set < CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y < CONFIG_DEBUG_STACK_USAGE=y --- > # CONFIG_DEBUG_KMEMLEAK is not set > # CONFIG_DEBUG_STACK_USAGE is not set 5548,5551c5540 < CONFIG_DETECT_HUNG_TASK=y < CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
Re: [PATCH] xtensa: remove unused XTENSA_ISS_NETWORK Kconfig parameter
On Mon, Nov 4, 2013 at 1:32 PM, Michael Opdenacker wrote: > This removes the XTENSA_ISS_NETWORK Kconfig parameter, > which was no longer used anywhere in the source code > and Makefiles. > > Signed-off-by: Michael Opdenacker > --- Thanks, taken to my xtensa tree. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Sat, Nov 09, 2013 at 09:37:31PM +0100, Geert Uytterhoeven wrote: > Add a DTS and defconfig for the Terasic DE0-Nano Development and Education > Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with > support chips and I/O. > > The DTS was derived from published versions by Kevin Mehall and Marek > Czerski. To give credit where credit is due, this was created by: Gong Tao > > Signed-off-by: Geert Uytterhoeven > Cc: Kevin Mehall > Cc: Marek Czerski > --- > Notable changes: > - Change flash0 to spansion,s25sl064p, due to kernel message > m25p80 spi32766.0: found s25sl064p, expected m25p10 This is due to Altera changing the EPCS chip on newer revisions of that board, older versions are "relabeled" m25p10 and newer once s25sl064p. The change is fine though, you have to pick one. Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
On Fri, 8 Nov 2013, Stephen Boyd wrote: > If we're running on a v7 ARM CPU, detect if the CPU supports the > sdiv/udiv instructions and replace the signed and unsigned > division library functions with an sdiv/udiv instruction. > > Running the perf messaging benchmark in pipe mode > > $ perf bench sched messaging -p > > shows a modest improvement on my v7 CPU. > > before: > (5.060 + 5.960 + 5.971 + 5.643 + 6.029 + 5.665 + 6.050 + 5.870 + 6.117 + > 5.683) / 10 = 5.805 > > after: > (4.884 + 5.549 + 5.749 + 6.001 + 5.460 + 5.103 + 5.956 + 6.112 + 5.468 + > 5.093) / 10 = 5.538 > > (5.805 - 5.538) / 5.805 = 4.6% > > Signed-off-by: Stephen Boyd Bah. NAK. We are doing runtime patching of the kernel for many many things already. So why not do the same here? The obvious strategy is to simply overwrite the start of the existing __aeabi_idiv code with the "sdiv r0, r0, r1" and "bx lr" opcodes. Similarly for the unsigned case. That let you test the hardware capability only once during boot instead of everytime a divide operation is performed. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] First round of SCSI updates for the 3.11+ merge window
This patch set is driver updates for qla4xxx, scsi_debug, pm80xx, fcoe/libfc, eas2r, lpfc, be2iscsi and megaraid_sas plus some assorted bug fixes and cleanups The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-for-linus The short changelog is: Aaron Lu (1): sd: call blk_pm_runtime_init before add_disk Adheer Chandravanshi (7): qla4xxx: Add support to get CHAP details for flash target session qla4xxx: Add support to set CHAP entries scsi_transport_iscsi: Add support to set CHAP entries qla4xxx: Use offset based on adapter type to set CHAP entry in flash qla4xxx: Populate local CHAP credentials for flash target sessions qla4xxx: Support setting of local CHAP index for flash target entry qla4xxx: Correct the check for local CHAP entry type Akinobu Mita (5): scsi_debug: fix sparse warnings related to data integrity field scsi_debug: fix invalid value check for guard module parameter scsi_debug: avoid partial copying PI from prot_sglist to dif_storep scsi_debug: factor out copying PI from dif_storep to prot_sglist scsi_debug: fix buffer overrun when DIF/DIX is enabled and virtual_gb > 0 Anand Kumar Santhanam (10): pm80xx: Firmware logging support. pm80xx: Phy settings support for motherboard controller. pm80xx: IButton security feature support for motherboard controllers. pm80xx: Print SAS address of IO failed device. pm80xx: 4G boundary fix. pm80xx: Queue rotation logic for inbound and outbound queues. pm80xx: Set device state response logic fix. pm80xx: Display controller BIOS version. pm80xx: Indirect SMP request fix. pm80xx: Device id changes to support series 8 controllers. Bart Van Assche (13): fcoe: Reduce fcoe_sysfs_fcf_add() stack usage fcoe: Add missing newlines in debug messages fcoe: Declare fcoe_ctlr_mode_set() static fcp: Do not interpret check condition as underrun libfc: Do not invoke the response handler after fc_exch_done() libfc: Reduce exchange lock contention in fc_exch_recv_abts() libfc: Avoid that sending after an abort triggers a kernel warning libfc: Protect ep->esb_stat changes via ex_lock libfc: Fix a race in fc_exch_timer_set_locked() libfc: Clarify fc_exch_find() libfc: Micro-optimize fc_setup_exch_mgr() libfc: Debug code fixes libfc: Source code comment spelling fixes Bernd Schubert (1): sd: Reduce buffer size for vpd request Bradley Grove (4): esas2r: Cleanup snprinf formatting of firmware version esas2r: Remove superfluous mask of pcie_cap_reg esas2r: Fixes for big-endian platforms esas2r: Directly call kernel functions for atomic bit operations Chad Dupuis (1): qla2xxx: Fix request queue null dereference. Chris Leech (1): iscsi_tcp: consider session state in iscsi_sw_sk_state_check Eddie Wai (4): MAINTAINER: Updated maintainer info for bnx2fc bnx2fc: Bump version from 1.0.14 to 2.4.1 BNX2FC: hung task timeout warning observed when rmmod bnx2x with active FCoE targets bnx2fc: Fixed a SCSI CMD cmpl race condition between ABTS and CLEANUP Felipe Pena (1): lpfc: Fix typo on NULL assignment Hannes Reinecke (8): scsi_error: Escalate to LUN reset if abort fails Add 'eh_deadline' to limit SCSI EH runtime remove check for 'resetting' dc395: Move 'last_reset' into internal host structure tmscsim: Move 'last_reset' into host structure advansys: Remove 'last_reset' references dpt_i2o: return SCSI_MLQUEUE_HOST_BUSY when in reset dpt_i2o: Remove DPTI_STATE_IOCTL Hiral Patel (2): fnic: Incremented driver version fnic: Fnic Statistics Collection Jack Wang (1): export device_busy for sdev James Bottomley (1): Derive the FLUSH_TIMEOUT from the basic I/O timeout James Smart (8): lpfc 8.3.43: Update lpfc version to driver version 8.3.43 lpfc 8.3.43: Fixed not processing task management IOCB response status lpfc 8.3.43: Fixed spinlock hang. lpfc 8.3.43: Fixed invalid Total_Data_Placed value received for els and ct command responses lpfc 8.3.43: Fixed invalid fcp_rsp length fir FCP_ICMND lpfc 8.3.43: Fixed invalid mailbox timeouts lpfc 8.3.43: Fixed spinlock inversion problem. lpfc 8.3.43: Fix crash after xri limit is reached. Jayamohan Kallickal (23): be2iscsi: Bump driver version be2iscsi: Fix SGL posting for unaligned ICD values be2iscsi: Fix AER handling in driver be2iscsi: Invalidate WRB in Abort/Reset Path be2iscsi: Fix Insufficient Buffer Error returned in MBX Completion be2iscsi: Fix log level for protocol specific logs be2iscsi: Fix MSIx creation for SKH-R adapter be2iscsi: Display Port Identifier for each iSCSI function be2iscsi: Dispaly CID available for connection
Re: Is there a notification mechanism for enabled/disabled trace events?
Hi Steven, thanks for your reply! On Thu, Nov 7, 2013 at 11:04 PM, Steven Rostedt wrote: > On Thu, 7 Nov 2013 17:42:54 +0900 > Alexandre Courbot wrote: > >> Hi everyone, >> >> Trace events can be enabled through debugfs by e.g. writing '1' into >> their enable node. This is a very useful feature as some tracing >> functions can introduce overhead and we only want them active when >> needed. >> >> There is one additional thing that I would need though, which is to be >> notified when a given trace event is enabled or disabled. >> >> Here is why: I have a power monitoring hardware that can report how >> much power is currently used by the system. Having this information >> correlated with other traces (cpufreq, cpuidle, ...) is very useful ; >> it can be done by repeatedly scheduling a work that probes the power >> usage and traces it. The job should only be running when the power >> monitoring trace event is enabled, but AFAIK there is no way to be >> notified when it is enabled or disabled. So here are a few questions: > > I'm a little confused by this. Your power monitoring is only enabled > when someone enables the power tracepoints? Why not have the user start > monitoring and have it enable the tracepoints itself? Mostly, for convenience reasons. There are quite a few user-space tools that configure and control kernel tracing more conveniently, using the trace events debugfs interface. Having a separate control to enable current probing would add one step to the setup, and I wondered if I could not reuse what exists already. >> 1) Is there such a notification mechanism for trace events that I have >> missed? > > That you missed? Can you elaborate here. I was just wondering if what I was looking for already existed - which seems to be the case. >> 2) If not, is there any objection to having one? I'd say my use-case >> is not so uncommon and others would certainly benefit from it. >> >> 3) What would be the right place to have it? ftrace_event_reg() looks >> like a good place to call a notifier chain, however I'm not sure where >> the notifier head should be stored, due to my poor understanding of >> ftrace. > > There is a way to hard code a notifier for tracepoints, look at how > TRACE_EVENT_FN() is used (include/trace/events/syscalls.h) > > But having a generic notifier may not be too hard or invasive to > implement. TRACE_EVENT_FN() is actually what I was looking for! Using it and a few registration functions for drivers to be notified when the event's status changes, it is quite easy to achieve what I wanted. With that in mind, it is probably not worth to make the trace events bigger by adding a generic notification mechanism to them, unless more potential users show up. 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/
Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
On Nov 3, 2013, Linus Torvalds wrote: > we'll have 4.0 follow 3.19 or something like that. > we could do a release with just stability and bug-fixes > the reason I mention "4.0" is that it would be a lovely time to do > that. That sounds backwards. .0s are known for instability and major new features that justify the major version number bump. A fixes-only release would make more sense as a last breath of the 3.* series, before (or even after?) 4.0 comes out. One way this might work is with a shorter release cycle after 3.19, with a fixes-only merge window, which would lead to a shorter stabilization cycle than usual, a rock-solid 3.20 release at the end of that cycle, during which new features would presumably have piled up for longer than usual, so as to make for more new features in the subsequent merge window, which would then justify a bump to 4.0. The shorter cycle towards 3.20, which would make the 2 cycles towards 4.0 shorter than two usual cycles, may help relieve some of the pressure to get features into 3.19, since the merge window for 4.0 won't be that far off. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] update xfs maintainers
Dave is on the other side of the international date line from those of us in the States. If my time zone math is correct, this thread began and continued *after* the end of his 'normal' Friday workday, during Dave's weekend. You think it might be possible he decided to unplug and actually live for a couple of days? Put this on hold until Monday. -- Stan On 11/9/2013 6:30 PM, Ben Myers wrote: > Dave, > > On Sat, Nov 09, 2013 at 05:51:30PM -0600, Ben Myers wrote: >> Hey Neil, >> >> On Sat, Nov 09, 2013 at 10:44:24AM +1100, NeilBrown wrote: >>> On Sat, 9 Nov 2013 06:59:00 +0800 Zhi Yong Wu wrote: >>> On Sat, Nov 9, 2013 at 6:03 AM, Ben Myers wrote: > Hey Ric, > > On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote: >> On 11/08/2013 03:46 PM, Ben Myers wrote: >>> Hey Christoph, >>> >>> On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote: On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote: > Mark is replacing Alex as my backup because Alex is really busy at > Linaro and asked to be taken off awhile ago. The holiday season is > coming up and I fully intend to go off my meds, turn in to Fonzy the > bear, and eat my hat. I need someone to watch the shop while I'm off > exploring on Mars. I trust Mark to do that because he is totally > awesome. Doing this as an unilateral decisions is not something that will win you a fan base. >>> It's posted for review. >>> While we never had anything reassembling a democracy in Linux Kernel development making decisions without even contacting the major contributor is wrong, twice so if the maintainer is a relatively minor contributor to start with. Just because it recent came up elsewhere I'd like to recite the definition from Trond here again: http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/66.html By many of the creative roles enlisted there it's clear that Dave should be the maintainer. He's been the main contributor and chief architect for XFS for many year, while the maintainers came and went at the mercy of SGI. This is not meant to bad mouth either of you as I think you're doing a reasonably good job compared to other maintainers, but at the same time the direction is set by other people that have a much longer involvement with the project, and having them officially in control would help us forward a lot. It would also avoid having to spend considerable resources to train every new generation of SGI maintainer. Coming to and end I would like to maintain Dave Chinner as the primary XFS maintainer for all the work he has done as biggest contributor and architect of XFS since longer than I can remember, and I would love to retain Ben Myers as a co-maintainer for all the good work he has done maintaining and reviewing patches since November 2011. >>> I think we're doing a decent job too. So thanks for that much at >>> least. ;) I would also like to use this post as a public venue to condemn the unilateral smokey backroom decisions about XFS maintainership that SGI is trying to enforce on the community. >>> That really didn't happen Christoph. It's not in my tree or in a pull >>> request. >>> >>> Linus, let me know what you want to do. I do think we're doing a fair >>> job over >>> here, and (geez) I'm just trying to add Mark as my backup since Alex is >>> too >>> busy. I know the RH people want more control, and that's >>> understandable, but >>> they really don't need to replace me to get their code in. Ouch. >>> >>> Thanks, >>> Ben >> >> Christoph is not a Red Hat person. >> >> Jeff is from Oracle. >> >> This is not a Red Hat vs SGI thing, > > Sorry if my read on that was wrong. > >> Dave simply has earned the right >> to take on the formal leadership role of maintainer. > > Then we're gonna need some Reviewed-bys. ;) > > From: Ben Myers > > xfs: update maintainers > > Add Dave as maintainer of XFS. > > Signed-off-by: Ben Myers > --- > MAINTAINERS |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: b/MAINTAINERS > === > --- a/MAINTAINERS 2013-11-08 15:20:18.935186245 -0600 > +++ b/MAINTAINERS 2013-11-08 15:22:50.685245977 -0600 > @@ -9387,8 +9387,8 @@ F:drivers/xen/*swiotlb* > > XFS FILESYSTEM > P: Silicon Graphics Inc > +M: Dave Chinner Use his personal
Cross thread shutdown of connected UDP socket, unexpected recvfrom behavior
Hi LKML,
I have a C/pthreads program with two threads ("main" and "thread").
"thread" calls recvfrom on a connected UDP socket and blocks, waiting
for input. "main" then calls shutdown SHUT_RD on the socket. In
"thread", recvfrom returns, apparently successfully, returning a zero
length string, and setting src_addr to a bogus(?) address family,
port, and source address.
Is the above the correct behavior for recvfrom?
Here is output from my program. "main" sends "hello\0", then "" (the
empty string), then calls shutdown. "thread" receives "hello\0", "",
and then finally receives an empty string that was never sent!
thread recvfrom: Success
rv 6 addrlen 16 fam 2 port 8000 addr 17f
thread recvfrom: Success
rv 0 addrlen 16 fam 2 port 8000 addr 17f
mainshutdown: Success
rv 0
thread recvfrom: Success
rv 0 addrlen 16 fam 59060 port 44237 addr deaadef0
The source code (2k) for the porgram is attached. I'm running Ubuntu
13.04, kernel 3.8.0-19-generic #30-Ubuntu, on 32-bit i686.
For reference, this June 2000 LKML thread discusses calling close in a
similar situation.
http://www.gossamer-threads.com/lists/linux/kernel/144379
Please CC me if you have questions, otherwise I'll try to watch for
answers in the list archives.
Thanks!
-mpb
#include
#include
#include
#include
#include
struct sockaddr_in addr_0, addr_1, addr_2 ;
int fd0, fd1, rv0, rv1, addrlen;
charbuf_0[1024], buf_1[1024];
pthread_t thread;
void* thread_rv;
void* thread_main (void* arg) {
int i; for ( i=0; i<3; i++ ) {
addr_2.sin_family = 0;
addr_2.sin_port = 0;
addr_2.sin_addr.s_addr = 0;
addrlen = sizeof addr_2;
rv1 = recvfrom ( fd1, buf_0, sizeof buf_0, 0,
(struct sockaddr*) _2, );
int fam = addr_2.sin_family;
int port = addr_2.sin_port;
int addr = addr_2.sin_addr.s_addr;
printf ("\n");
perror ("thread recvfrom");
printf ( " rv %d addrlen %d fam %d port %d addr %x\n",
rv1, addrlen, fam, ntohs (port), addr );
;;; }
return NULL; }
void main_main () {
send ( fd0, "hello", 6, 0);
send ( fd0, "", 0, 0);
usleep (10);
rv0 = shutdown ( fd1, SHUT_RD );
printf ("\n");
perror ("mainshutdown");
printf (" %d\n", rv0)
;;; }
int main () {
addr_0.sin_family = AF_INET;
addr_0.sin_port = htons (8000);
inet_pton ( AF_INET, "127.0.0.1", _0.sin_addr );
addr_1.sin_family = AF_INET;
addr_1.sin_port = htons (8001);
inet_pton ( AF_INET, "127.0.0.1", _1.sin_addr );
fd0 = socket ( AF_INET, SOCK_DGRAM, 0 );
bind( fd0, (struct sockaddr*) _0, sizeof addr_0 );
connect ( fd0, (struct sockaddr*) _1, sizeof addr_1 );
fd1 = socket ( AF_INET, SOCK_DGRAM, 0 );
bind( fd1, (struct sockaddr*) _1, sizeof addr_1 );
connect ( fd1, (struct sockaddr*) _0, sizeof addr_0 );
pthread_create ( , NULL, thread_main, NULL );
main_main ();
pthread_join ( thread, _rv );
return 0; }
Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Am Samstag, 9. November 2013, 23:04:07 schrieb Clemens Ladisch: Hi Clemens, > Stephan Mueller wrote: > > Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire: > >> On Wed, 06 Nov 2013, Stephan Mueller wrote: > >>> Besides, how on earth shall an attacker even gain knowledge about the > >>> state of the CPU or disable CPU mechanisms? Oh, I forgot, your NSA > >>> guy. But if he is able to do that, all discussions are moot because > >>> he simply disables any noise sources by flipping a bit, reads the > >>> memory that is used to hold the state of the RNG or just overwrites > >>> the memory locations where data is collected, because the general > >>> protection mechanisms offered by the kernel and the underlying > >>> hardware are broken. > >> > >> No need to gain knowledge of the internal CPU state itt would be > >> sufficient to be able to put the CPU in a sub-state-space in which > >> the distribution is shifted. it may be enough to reduce the truely > >> random bits of some key only by a few bits to make it suceptible to > >> brute force attacks. > > > > Note, the proposed RNG contains an unbias operation (the Von-Neumann > > unbiaser) which is proven to remove any bias when it is established that > > the individual observations are independent. And the way the > > observations are generated ensures that they are independent. > > "Independent" does not mean that your own code avoids reusing data from > the previous loop iteration; it means that the _entire_ process that > generates the bits is not affected by any memory of the past. In the other email, I explained the different types of tests I performed. All of these tests show proper statistical results. Now, I also performed these tests without the Von-Neumann unbiaser. All of the statistical tests results still showed a white noise (note, in the next code release, I will have an allocation flag added that you can use to very simply deactivate the Von-Neumann unbiaser for testing). So, the Von-Neumann unbiaser is to be considered a line of defence against (not yet observed, but potential) skews. Similarly, the optional whitening (non-cryptographic) function of jent_stir_pool is yet another line of defence. So, bottom line: I fully concur that using two separate measurements may not imply that they are independent. But testing shows that it does not matter. > > The observations are derived from the internal CPU state, which is *not* > reset between measurements. > > > Regards, > Clemens Ciao Stephan -- | Cui bono? | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Am Samstag, 9. November 2013, 23:04:49 schrieb Clemens Ladisch: Hi Clemens, > Stephan Mueller wrote: > > Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o: > >> On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote: > That's unfortunate, since it leaves open the question of whether this > jitter is something that could be at least somewhat predictable if you > had a lot more information about the internal works of the CPU or > not > >>> > >>> I do not understand that answer: I thought we are talking about the > >>> search of non-predictable noise sources. If you cannot predict the > >>> sequence even if you have the state of the CPU, that is what we are > >>> looking for, is it not? > >> > >> I was asking the question about whether someone who knew more about > >> the internal _workings_ of the CPU, note of the state of the CPU. > >> This is not necessarily "the NSA guy", but someone who knows more > >> about the internal workings of the Intel CPU (such as an Intel > >> engineer --- and I've had Intel express misgivings about approaches > >> which depend on "CPU jitter" approaches), or just someone who has > >> spent a lot more time trying to examine the black box of the Intel CPU > >> from the outside. > > > > I try to get more information from my contacts to other vendors. But I > > am wondering what shall we do if the answer is (maybe even proven with > > some test results) that they see the same issue themselves and have no > > handle on it? > > > > I mean, what is it that I would need to test and demonstrate to prove or > > disprove my RNG? > > You need to prove that the CPU will never get into an internal state > where the loop execution times happen to form a predictable pattern. > Alternatively, detect this so that the measurements can be thrown away. That statement sounds very nice, and I would love to prove it. But I do not see any way to do that except applying statistical tests on a large number of different systems and by disabling CPU features -- as I have done. I am fully aware that statistical tests cannot prove the conclusion that the noise source is proper. But we have to keep requirements to my RNG in league with the research applied to other noise sources. Let us look at physical noise sources we all know and love: - The conclusion that radioactive decay is random is based on the quantum theory. That theory contains a number of formulas which were all validated with a plethora of measurements. Yet, there is no proof (in the mathematical sense) that the formulas are correct. These formulas are based on deductive science but *not* inductive science (like math). - Oscillators: Again, the conclusion of oscillators being appropriate depends on deductive science. - Shot noise, Johnson noise, etc. of resistors, transistors is again based on deductive science. For software: - The noise sources of interrupts, HID events, HDD fluctuations are all based on deductive science. There is even no formulas or other mathematical model behind them to state that they are good for RNGs. So, there was never a proof in the sense of an inductive science of any noise source. That means I cannot be expected to show a full formulated proof based on inductive science of the noise source I offer here. Yet, I meet the deductive science approach with my RNG as I base my conclusions on a large array of measurements. And I give the tools to perform the measurements to everybody. So, everybody can easily redo the testing, or, if possible, prove me wrong! You may look into [1] and [2]. [1] mentions that inductive methods cannot reach absolute proof. > > > We can certainly test very much, but one thing we cannot prove, and > > that is the fundamental jitter, provided it is a result of quantum > > fluctuations. Just as with any other noise source, basic fundamental > > principles are hard if not impossible to test. > > You cannot test if the noise source was replaced with fake hardware. > But if you know the characteristics of the noise source, you can test > for likely failure modes, such as the output value being stuck or > oscillating. And here I am asking for help! What did I do so far: - Test the CPU in kernel and user mode. - Selectively and mutually disable CPU features (see appendix F.46 of my documentation). - Tested on quiet and heavily loaded CPUs. - Testing on the same physical system / CPU with different operating systems. What else can I do? When you ask for testing of stuck values, what shall I really test for? Shall I test adjacent measurements for the same or alternating values? The test for the same values is caught with the Von-Neumann unbiaser. If I test for alternating values, other people may come in and ask to check for pattern x or y. But then, section 4.3 of my document contains an analysis of patterns. As I do not use a whitener, any pattern WILL be visible with the Chi-Square test result. All
[PATCH] ACPI / driver core: Store a device pointer in struct acpi_dev_node
From: Rafael J. Wysocki
Modify struct acpi_dev_node to contain a pointer to struct device
ambedded in the struct acpi_device associated with the given device
object (that is, its ACPI companion device) instead of an ACPI handle
corresponding to that struct acpi_device. Introduce two new macros
for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The rationale for using a struct device pointer instead of a
struct acpi_device one as the member of struct acpi_dev_node is
that it allows device.h to avoid including linux/acpi.h which would
introduce quite a bit of compilation overhead for stuff that doesn't
care about ACPI. In turn, moving the macros to linux/acpi.h forces
the stuff that does care about ACPI to include that file as
appropriate anyway.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, it should help to reduce the number
of places in which the result of ACPI_HANDLE() is passed to
acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer can be obtained directly by applying
to_acpi_device() to the result of the ACPI_COMPANION() macro.
Finally, it should make it easier to write generic code that will
build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki
---
Hi Everybody,
First of all, I haven't tested this yet, so caveat emptor. I have compiled
it on x86-64 for CONFIG_ACPI set and unset and I'm going to feed it to the
auto build system shortly in case I overlooked something build-related.
Please have a look and let me know if you have any problems with this in
principle. If not, I'd like to queue it up for inclusion by the end of
the merge window or in the -rc2 time frame (to avoid collisions with any
big merges), as I'd like to be able to work on top of it during the 3.14
cycle if possible.
Thanks,
Rafael
---
arch/ia64/include/asm/pci.h |2 -
arch/ia64/pci/pci.c |6 ++---
arch/x86/include/asm/pci.h|2 -
arch/x86/pci/acpi.c |4 +--
drivers/acpi/acpi_platform.c |2 -
drivers/acpi/device_pm.c |6 -
drivers/acpi/glue.c | 45 +-
drivers/ata/libata-acpi.c |4 +--
drivers/base/platform.c |4 +--
drivers/hid/i2c-hid/i2c-hid.c |2 -
drivers/i2c/i2c-core.c|4 +--
drivers/mmc/core/sdio_bus.c |3 --
drivers/spi/spi.c |2 -
include/acpi/acpi_bus.h |2 -
include/linux/acpi.h | 14 +
include/linux/device.h| 10 -
16 files changed, 57 insertions(+), 55 deletions(-)
Index: linux-pm/include/linux/device.h
===
--- linux-pm.orig/include/linux/device.h
+++ linux-pm/include/linux/device.h
@@ -625,7 +625,7 @@ struct device_dma_parameters {
struct acpi_dev_node {
#ifdef CONFIG_ACPI
- void*handle;
+ struct device *dev;
#endif
};
@@ -769,14 +769,6 @@ static inline struct device *kobj_to_dev
return container_of(kobj, struct device, kobj);
}
-#ifdef CONFIG_ACPI
-#define ACPI_HANDLE(dev) ((dev)->acpi_node.handle)
-#define ACPI_HANDLE_SET(dev, _handle_) (dev)->acpi_node.handle = (_handle_)
-#else
-#define ACPI_HANDLE(dev) (NULL)
-#define ACPI_HANDLE_SET(dev, _handle_) do { } while (0)
-#endif
-
/* Get the wakeup routines, which depend on struct device */
#include
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -431,9 +431,9 @@ static inline acpi_handle acpi_get_child
{
return acpi_find_child(handle, addr, false);
}
+void acpi_preset_companion(struct device *dev, acpi_handle parent, u64 addr);
int acpi_is_root_bridge(acpi_handle);
struct acpi_pci_root
Re: [PATCH] update xfs maintainers
Dave, On Sat, Nov 09, 2013 at 05:51:30PM -0600, Ben Myers wrote: > Hey Neil, > > On Sat, Nov 09, 2013 at 10:44:24AM +1100, NeilBrown wrote: > > On Sat, 9 Nov 2013 06:59:00 +0800 Zhi Yong Wu wrote: > > > > > On Sat, Nov 9, 2013 at 6:03 AM, Ben Myers wrote: > > > > Hey Ric, > > > > > > > > On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote: > > > >> On 11/08/2013 03:46 PM, Ben Myers wrote: > > > >> >Hey Christoph, > > > >> > > > > >> >On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote: > > > >> >>On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote: > > > >> >>>Mark is replacing Alex as my backup because Alex is really busy at > > > >> >>>Linaro and asked to be taken off awhile ago. The holiday season is > > > >> >>>coming up and I fully intend to go off my meds, turn in to Fonzy the > > > >> >>>bear, and eat my hat. I need someone to watch the shop while I'm > > > >> >>>off > > > >> >>>exploring on Mars. I trust Mark to do that because he is totally > > > >> >>>awesome. > > > >> >> > > > >> >>Doing this as an unilateral decisions is not something that will win > > > >> >>you > > > >> >>a fan base. > > > >> >It's posted for review. > > > >> > > > > >> >>While we never had anything reassembling a democracy in Linux Kernel > > > >> >>development making decisions without even contacting the major > > > >> >>contributor is wrong, twice so if the maintainer is a relatively > > > >> >>minor > > > >> >>contributor to start with. > > > >> >> > > > >> >>Just because it recent came up elsewhere I'd like to recite the > > > >> >>definition from Trond here again: > > > >> >> > > > >> >> > > > >> >> http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/66.html > > > >> >> > > > >> >>By many of the creative roles enlisted there it's clear that Dave > > > >> >>should > > > >> >>be the maintainer. He's been the main contributor and chief > > > >> >>architect > > > >> >>for XFS for many year, while the maintainers came and went at the > > > >> >>mercy > > > >> >>of SGI. This is not meant to bad mouth either of you as I think > > > >> >>you're > > > >> >>doing a reasonably good job compared to other maintainers, but at the > > > >> >>same time the direction is set by other people that have a much > > > >> >>longer > > > >> >>involvement with the project, and having them officially in control > > > >> >>would help us forward a lot. It would also avoid having to spend > > > >> >>considerable resources to train every new generation of SGI > > > >> >>maintainer. > > > >> >> > > > >> >>Coming to and end I would like to maintain Dave Chinner as the > > > >> >>primary > > > >> >>XFS maintainer for all the work he has done as biggest contributor > > > >> >>and > > > >> >>architect of XFS since longer than I can remember, and I would love > > > >> >>to > > > >> >>retain Ben Myers as a co-maintainer for all the good work he has done > > > >> >>maintaining and reviewing patches since November 2011. > > > >> >I think we're doing a decent job too. So thanks for that much at > > > >> >least. ;) > > > >> >>I would also like to use this post as a public venue to condemn the > > > >> >>unilateral smokey backroom decisions about XFS maintainership that > > > >> >>SGI is > > > >> >>trying to enforce on the community. > > > >> >That really didn't happen Christoph. It's not in my tree or in a > > > >> >pull request. > > > >> > > > > >> >Linus, let me know what you want to do. I do think we're doing a > > > >> >fair job over > > > >> >here, and (geez) I'm just trying to add Mark as my backup since Alex > > > >> >is too > > > >> >busy. I know the RH people want more control, and that's > > > >> >understandable, but > > > >> >they really don't need to replace me to get their code in. Ouch. > > > >> > > > > >> >Thanks, > > > >> > Ben > > > >> > > > >> Christoph is not a Red Hat person. > > > >> > > > >> Jeff is from Oracle. > > > >> > > > >> This is not a Red Hat vs SGI thing, > > > > > > > > Sorry if my read on that was wrong. > > > > > > > >> Dave simply has earned the right > > > >> to take on the formal leadership role of maintainer. > > > > > > > > Then we're gonna need some Reviewed-bys. ;) > > > > > > > > From: Ben Myers > > > > > > > > xfs: update maintainers > > > > > > > > Add Dave as maintainer of XFS. > > > > > > > > Signed-off-by: Ben Myers > > > > --- > > > > MAINTAINERS |2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > Index: b/MAINTAINERS > > > > === > > > > --- a/MAINTAINERS 2013-11-08 15:20:18.935186245 -0600 > > > > +++ b/MAINTAINERS 2013-11-08 15:22:50.685245977 -0600 > > > > @@ -9387,8 +9387,8 @@ F:drivers/xen/*swiotlb* > > > > > > > > XFS FILESYSTEM > > > > P: Silicon Graphics Inc > > > > +M: Dave Chinner > > > Use his personal private mail account? I guess that you should ask for > > > his opinion at
Re: [PATCH] ext4: explain encoding of 34-bit a,c,mtime values
On 8 November 2013 23:19, David Turner wrote:
>
> On Fri, 2013-11-08 at 14:37 -0700, Andreas Dilger wrote:
> > On Nov 7, 2013, at 4:26 PM, David Turner wrote:
> > > On Fri, 2013-11-08 at 00:14 +0100, Jan Kara wrote:
> > >> Still unnecessary type cast here (but that's a cosmetic issue).
> > > ...
> > >> Otherwise the patch looks good. You can add:
> > >> Reviewed-by: Jan Kara
> > >
> > > Thanks. A version with this correction and the reviewed-by follows.
> >
> > Thanks for working on this. It was (seriously) in my list of things to
> > get done, but I figured I still had a few years to work on it...
> >
> > My (unfinished) version of this patch had a nice comment at
> > ext4_encode_time()
> > that explained the encoding that is being used very clearly:
> >
> > /*
> > * We need is an encoding that preserves the times for extra epoch "00":
> > *
> > * extra msb of adjust for signed
> > * epoch 32-bit 32-bit tv_sec to
> > * bits timedecoded 64-bit tv_sec 64-bit tv_sec valid time range
> > * 0 01-0x8000..-0x0001 0x0
> > 1901-12-13..1969-12-31
> > * 0 000x0..0x07fff 0x0
> > 1970-01-01..2038-01-19
> > * 0 110x08000..0x0 0x1
> > 2038-01-19..2106-02-07
> > * 0 100x1..0x17fff 0x1
> > 2106-02-07..2174-02-25
> > * 1 010x18000..0x1 0x2
> > 2174-02-25..2242-03-16
> > * 1 000x2..0x27fff 0x2
> > 2242-03-16..2310-04-04
> > * 1 110x28000..0x2 0x3
> > 2310-04-04..2378-04-22
> > * 1 100x3..0x37fff 0x3
> > 2378-04-22..2446-05-10
> > */
> >
> > It seems that your version of the patch seems to use a different encoding.
> > Not
> > that this is a problem, per-se, since my patch wasn’t in use anywhere, but
> > it
> > would be nice to have a similarly clear explanation of what the mapping is
> > so
> > that it can be clearly understood.
>
> I have included a patch with an explanation (the patch is against
> tytso/dev -- I hope that's the correct place).
>
> > My ext4_{encode,decode}_extra_time() used add/subtract instead of mask/OR
> > ops,
> > which changed the on-disk format for times beyond 2038, but those were
> > already
> > broken, and presumably not in use by anyone yet.
>
> They were actually correct according to my patch's encoding (that is, my
> patch used the existing encoding). The existing encoding was written
> correctly, but read wrongly. As you say, this should not matter, since
> nobody should be writing these timestamps, but I assumed that the
> existing encoding had happened for a reason, and wanted to make the
> minimal change.
>
> If you believe it is important, I would be happy to change it.
The problem with the existing encoding is that pre-1970 dates are
encoded with extra bits 1,1 in 64-bit kernels with ext4, but on 32-bit
kernels and inodes that were originally written as ext3 the extra bits
will be 0,0. Currently, both are decoded as pre-1970 dates.
With your patch, only the 1,1 format used by 64-bit ext4 will decode
as a pre-1970 date. Dates previously written by ext3 or a 32-bit
kernel will no longer be decoded as expected. Also the patch does
not update ext4_encode_extra_time to use this format for pre-1970
dates in 32-bit mode.
Possible solutions were discussed here, but no decision was made:
http://thread.gmane.org/gmane.comp.file-systems.ext4/26087/focus=26406
>
>
> > However, it seemed to me this
> > was easier to produce the correct results. Have you tested your patch with
> > a variety of timestamps to verify its correctness?
>
> I tested by using touch -d to create one file in each year between 1902
> and 2446. Then I unmounted and remounted the FS, and did ls -l and
> manually verified that each file's date matched its name.
>
> > It looks to me like you
> > have mapped the 1901-1969 range onto 0x3 for the epoch bits, instead
> > of the (IMHO) natural 0x0 bits. The critical time ranges are listed
> > above.
>
> I think the idea of this is that it is the bottom 34 bits of the 64-bit
> signed time. However, it occurs to me that this relies on a two's
> complement machine. Even though the C standard does not guarantee this,
> I believe the kernel requires it, so that's probably OK.
- Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] update xfs maintainers
Hey Neil, On Sat, Nov 09, 2013 at 10:44:24AM +1100, NeilBrown wrote: > On Sat, 9 Nov 2013 06:59:00 +0800 Zhi Yong Wu wrote: > > > On Sat, Nov 9, 2013 at 6:03 AM, Ben Myers wrote: > > > Hey Ric, > > > > > > On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote: > > >> On 11/08/2013 03:46 PM, Ben Myers wrote: > > >> >Hey Christoph, > > >> > > > >> >On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote: > > >> >>On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote: > > >> >>>Mark is replacing Alex as my backup because Alex is really busy at > > >> >>>Linaro and asked to be taken off awhile ago. The holiday season is > > >> >>>coming up and I fully intend to go off my meds, turn in to Fonzy the > > >> >>>bear, and eat my hat. I need someone to watch the shop while I'm off > > >> >>>exploring on Mars. I trust Mark to do that because he is totally > > >> >>>awesome. > > >> >> > > >> >>Doing this as an unilateral decisions is not something that will win > > >> >>you > > >> >>a fan base. > > >> >It's posted for review. > > >> > > > >> >>While we never had anything reassembling a democracy in Linux Kernel > > >> >>development making decisions without even contacting the major > > >> >>contributor is wrong, twice so if the maintainer is a relatively minor > > >> >>contributor to start with. > > >> >> > > >> >>Just because it recent came up elsewhere I'd like to recite the > > >> >>definition from Trond here again: > > >> >> > > >> >> > > >> >> http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/66.html > > >> >> > > >> >>By many of the creative roles enlisted there it's clear that Dave > > >> >>should > > >> >>be the maintainer. He's been the main contributor and chief architect > > >> >>for XFS for many year, while the maintainers came and went at the mercy > > >> >>of SGI. This is not meant to bad mouth either of you as I think you're > > >> >>doing a reasonably good job compared to other maintainers, but at the > > >> >>same time the direction is set by other people that have a much longer > > >> >>involvement with the project, and having them officially in control > > >> >>would help us forward a lot. It would also avoid having to spend > > >> >>considerable resources to train every new generation of SGI maintainer. > > >> >> > > >> >>Coming to and end I would like to maintain Dave Chinner as the primary > > >> >>XFS maintainer for all the work he has done as biggest contributor and > > >> >>architect of XFS since longer than I can remember, and I would love to > > >> >>retain Ben Myers as a co-maintainer for all the good work he has done > > >> >>maintaining and reviewing patches since November 2011. > > >> >I think we're doing a decent job too. So thanks for that much at > > >> >least. ;) > > >> >>I would also like to use this post as a public venue to condemn the > > >> >>unilateral smokey backroom decisions about XFS maintainership that SGI > > >> >>is > > >> >>trying to enforce on the community. > > >> >That really didn't happen Christoph. It's not in my tree or in a pull > > >> >request. > > >> > > > >> >Linus, let me know what you want to do. I do think we're doing a fair > > >> >job over > > >> >here, and (geez) I'm just trying to add Mark as my backup since Alex is > > >> >too > > >> >busy. I know the RH people want more control, and that's > > >> >understandable, but > > >> >they really don't need to replace me to get their code in. Ouch. > > >> > > > >> >Thanks, > > >> > Ben > > >> > > >> Christoph is not a Red Hat person. > > >> > > >> Jeff is from Oracle. > > >> > > >> This is not a Red Hat vs SGI thing, > > > > > > Sorry if my read on that was wrong. > > > > > >> Dave simply has earned the right > > >> to take on the formal leadership role of maintainer. > > > > > > Then we're gonna need some Reviewed-bys. ;) > > > > > > From: Ben Myers > > > > > > xfs: update maintainers > > > > > > Add Dave as maintainer of XFS. > > > > > > Signed-off-by: Ben Myers > > > --- > > > MAINTAINERS |2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Index: b/MAINTAINERS > > > === > > > --- a/MAINTAINERS 2013-11-08 15:20:18.935186245 -0600 > > > +++ b/MAINTAINERS 2013-11-08 15:22:50.685245977 -0600 > > > @@ -9387,8 +9387,8 @@ F:drivers/xen/*swiotlb* > > > > > > XFS FILESYSTEM > > > P: Silicon Graphics Inc > > > +M: Dave Chinner > > Use his personal private mail account? I guess that you should ask for > > his opinion at first, or it is more appropriate that he submit this > > patch by himself. If y'all don't mind, I'd like to have authored this one. ;) > Indeed. And does he even want the job? I heard Linus say in a recent > interview that being a maintainer is a $#!+ job. I've found that it can be a little bit stressful sometimes and it tends to crowd out feature work, so I guess I agree with him. It turns out
[patch] pinctrl: abx500: fix some more bitwise AND tests
I sent a patch to fix some bitwise AND tests but I guess I missed some. Sorry about that. Signed-off-by: Dan Carpenter diff --git a/drivers/pinctrl/pinctrl-abx500.c b/drivers/pinctrl/pinctrl-abx500.c index 4780959..5183e7bb 100644 --- a/drivers/pinctrl/pinctrl-abx500.c +++ b/drivers/pinctrl/pinctrl-abx500.c @@ -418,7 +418,7 @@ static int abx500_set_mode(struct pinctrl_dev *pctldev, struct gpio_chip *chip, ret = abx500_gpio_set_bits(chip, AB8500_GPIO_ALTFUN_REG, af.alt_bit1, - !!(af.alta_val && BIT(0))); + !!(af.alta_val & BIT(0))); if (ret < 0) goto out; @@ -439,7 +439,7 @@ static int abx500_set_mode(struct pinctrl_dev *pctldev, struct gpio_chip *chip, goto out; ret = abx500_gpio_set_bits(chip, AB8500_GPIO_ALTFUN_REG, - af.alt_bit1, !!(af.altb_val && BIT(0))); + af.alt_bit1, !!(af.altb_val & BIT(0))); if (ret < 0) goto out; @@ -462,7 +462,7 @@ static int abx500_set_mode(struct pinctrl_dev *pctldev, struct gpio_chip *chip, goto out; ret = abx500_gpio_set_bits(chip, AB8500_GPIO_ALTFUN_REG, - af.alt_bit2, !!(af.altc_val && BIT(1))); + af.alt_bit2, !!(af.altc_val & BIT(1))); break; default: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] update xfs maintainers
On Fri, Nov 08, 2013 at 06:32:33PM -0500, Ric Wheeler wrote: > On 11/08/2013 05:17 PM, Ben Myers wrote: > >Hey Ric, > > > >On Fri, Nov 08, 2013 at 05:07:45PM -0500, Ric Wheeler wrote: > >>On 11/08/2013 05:03 PM, Ben Myers wrote: > >>>Hey Ric, > >>> > >>>On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote: > On 11/08/2013 03:46 PM, Ben Myers wrote: > >Hey Christoph, > > > >On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote: > >>On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote: > >>>Mark is replacing Alex as my backup because Alex is really busy at > >>>Linaro and asked to be taken off awhile ago. The holiday season is > >>>coming up and I fully intend to go off my meds, turn in to Fonzy the > >>>bear, and eat my hat. I need someone to watch the shop while I'm off > >>>exploring on Mars. I trust Mark to do that because he is totally > >>>awesome. > >>Doing this as an unilateral decisions is not something that will win you > >>a fan base. > >It's posted for review. > > > >>While we never had anything reassembling a democracy in Linux Kernel > >>development making decisions without even contacting the major > >>contributor is wrong, twice so if the maintainer is a relatively minor > >>contributor to start with. > >> > >>Just because it recent came up elsewhere I'd like to recite the > >>definition from Trond here again: > >> > >> > >> http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/66.html > >> > >>By many of the creative roles enlisted there it's clear that Dave should > >>be the maintainer. He's been the main contributor and chief architect > >>for XFS for many year, while the maintainers came and went at the mercy > >>of SGI. This is not meant to bad mouth either of you as I think you're > >>doing a reasonably good job compared to other maintainers, but at the > >>same time the direction is set by other people that have a much longer > >>involvement with the project, and having them officially in control > >>would help us forward a lot. It would also avoid having to spend > >>considerable resources to train every new generation of SGI maintainer. > >> > >>Coming to and end I would like to maintain Dave Chinner as the primary > >>XFS maintainer for all the work he has done as biggest contributor and > >>architect of XFS since longer than I can remember, and I would love to > >>retain Ben Myers as a co-maintainer for all the good work he has done > >>maintaining and reviewing patches since November 2011. > >I think we're doing a decent job too. So thanks for that much at least. > > ;) > >>I would also like to use this post as a public venue to condemn the > >>unilateral smokey backroom decisions about XFS maintainership that SGI > >>is > >>trying to enforce on the community. > >That really didn't happen Christoph. It's not in my tree or in a pull > >request. > > > >Linus, let me know what you want to do. I do think we're doing a fair > >job over > >here, and (geez) I'm just trying to add Mark as my backup since Alex is > >too > >busy. I know the RH people want more control, and that's > >understandable, but > >they really don't need to replace me to get their code in. Ouch. > > > >Thanks, > > Ben > Christoph is not a Red Hat person. > > Jeff is from Oracle. > > This is not a Red Hat vs SGI thing, > >>>Sorry if my read on that was wrong. > >>I do appreciate the work and effort you and the SGI team put in but > >>think that this will be a good way to keep the community happier and > >>even more productive going forward. > >> > Dave simply has earned the right > to take on the formal leadership role of maintainer. > >>>Then we're gonna need some Reviewed-bys. ;) > >>Those should come from the developers, thanks! > >I actually do need your Reviewed-by. We'll try and get this one in 3.13. > >;) > > > >Thanks, > > Ben > > Happy to do that - I do think that Dave mostly posts from his > redhat.com account, but he can comment once he gets back online. > > Reviewed-by: Ric Wheeler Thanks Ric. ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] cgroup changes for v3.13-rc1
Hello, again.
Not too much activity this time around. css_id is finally killed and
a minor update to device_cgroup; however, the pull request does lead
to a conflict in mm/memcontrol.c between the following two commits.
b862783594847 ("memcg: stop using css id")
bb4cc1a8b5eaf ("revert "memcg: get rid of soft-limit tree infrastructure"")
The former removes free_css_id() call from __mem_cgroup_free() and the
latter restores mem_cgroup_remove_from_trees() right above it leading
to context conflict. The conflict looks like
static void __mem_cgroup_free(struct mem_cgroup *memcg)
{
int node;
size_t size = memcg_size();
<<< HEAD
mem_cgroup_remove_from_trees(memcg);
free_css_id(_cgroup_subsys, >css);
===
>>> 73ba353471e0b692f398f3d63018b7f46ccf1d3e
for_each_node(node)
free_mem_cgroup_per_zone_info(memcg, node);
free_percpu(memcg->stat);
and can be resolved like the following.
static void __mem_cgroup_free(struct mem_cgroup *memcg)
{
int node;
size_t size = memcg_size();
mem_cgroup_remove_from_trees(memcg);
for_each_node(node)
free_mem_cgroup_per_zone_info(memcg, node);
free_percpu(memcg->stat);
The changes are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-3.13
for you to fetch changes up to 73ba353471e0b692f398f3d63018b7f46ccf1d3e:
device_cgroup: remove can_attach (2013-10-24 06:56:56 -0400)
Just in case, the test merge is available in the following git branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git test-merge-3.13
Thanks.
Li Zefan (5):
memcg: convert to use cgroup_is_descendant()
memcg: convert to use cgroup id
memcg: fail to create cgroup if the cgroup id is too big
memcg: stop using css id
cgroup: kill css_id
Serge Hallyn (1):
device_cgroup: remove can_attach
include/linux/cgroup.h | 37 ---
kernel/cgroup.c | 248 +--
mm/memcontrol.c | 67 +++--
security/device_cgroup.c | 11 ---
4 files changed, 41 insertions(+), 322 deletions(-)
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] libata changes for v3.13-rc1
Hello, Linus. Nothing too interesting. Only two minor fixes in libata core. Most changes are specific to hardware which isn't too common. The patches are available in the following git branch git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-3.13 for you to fetch changes up to 9f961a5f6efc87a79571d7166257b36af28ffcfe: ahci: Add Device IDs for Intel Wildcat Point-LP (2013-11-04 16:03:39 -0500) Thanks. Chuansheng Liu (1): ahci: Changing two module params with static and __read_mostly Dan Carpenter (1): sata_highbank: clear whole array in highbank_initialize_phys() Gwendal Grignou (1): libata: Fix display of sata speed James Ralston (1): ahci: Add Device IDs for Intel Wildcat Point-LP Laurent Pinchart (1): sata_rcar: Convert to clk_prepare/unprepare Levente Kurusa (1): ata_piix: minor typo and a printk fix Richard Zhu (1): ahci: imx: setup power saving methods Robert Hancock (1): libata: Add some missing command descriptions Shan Hai (1): drivers/libata: Set max sector to 65535 for Slimtype DVD A DS8A9SH drive xiangliang yu (1): ahci: disabled FBS prior to issuing software reset drivers/ata/ahci.c | 4 ++ drivers/ata/ahci.h | 2 + drivers/ata/ahci_imx.c | 101 - drivers/ata/ahci_platform.c| 3 +- drivers/ata/ata_piix.c | 19 drivers/ata/libahci.c | 27 +-- drivers/ata/libata-core.c | 1 + drivers/ata/libata-eh.c| 8 drivers/ata/libata-transport.c | 16 +++ drivers/ata/sata_highbank.c| 8 ++-- drivers/ata/sata_rcar.c| 10 ++-- include/linux/ata.h| 7 +++ 12 files changed, 171 insertions(+), 35 deletions(-) -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Stephan Mueller wrote: > Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o: >> On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote: That's unfortunate, since it leaves open the question of whether this jitter is something that could be at least somewhat predictable if you had a lot more information about the internal works of the CPU or not >>> >>> I do not understand that answer: I thought we are talking about the >>> search of non-predictable noise sources. If you cannot predict the >>> sequence even if you have the state of the CPU, that is what we are >>> looking for, is it not? >> >> I was asking the question about whether someone who knew more about >> the internal _workings_ of the CPU, note of the state of the CPU. >> This is not necessarily "the NSA guy", but someone who knows more >> about the internal workings of the Intel CPU (such as an Intel >> engineer --- and I've had Intel express misgivings about approaches >> which depend on "CPU jitter" approaches), or just someone who has >> spent a lot more time trying to examine the black box of the Intel CPU >> from the outside. > > I try to get more information from my contacts to other vendors. But I > am wondering what shall we do if the answer is (maybe even proven with > some test results) that they see the same issue themselves and have no > handle on it? > > I mean, what is it that I would need to test and demonstrate to prove or > disprove my RNG? You need to prove that the CPU will never get into an internal state where the loop execution times happen to form a predictable pattern. Alternatively, detect this so that the measurements can be thrown away. > We can certainly test very much, but one thing we cannot prove, and > that is the fundamental jitter, provided it is a result of quantum > fluctuations. Just as with any other noise source, basic fundamental > principles are hard if not impossible to test. You cannot test if the noise source was replaced with fake hardware. But if you know the characteristics of the noise source, you can test for likely failure modes, such as the output value being stuck or oscillating. In the case of CPU jitter measurements, you do not have direct access to the noise source; you measure it indirectly through the CPU's internal state. So you need to know how the delta times of a noisy CPU are different from the delta times of a CPU without or with unsuitable noise source. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Stephan Mueller wrote: > Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire: >> On Wed, 06 Nov 2013, Stephan Mueller wrote: >>> Besides, how on earth shall an attacker even gain knowledge about the >>> state of the CPU or disable CPU mechanisms? Oh, I forgot, your NSA >>> guy. But if he is able to do that, all discussions are moot because >>> he simply disables any noise sources by flipping a bit, reads the >>> memory that is used to hold the state of the RNG or just overwrites >>> the memory locations where data is collected, because the general >>> protection mechanisms offered by the kernel and the underlying >>> hardware are broken. >> >> No need to gain knowledge of the internal CPU state itt would be >> sufficient to be able to put the CPU in a sub-state-space in which >> the distribution is shifted. it may be enough to reduce the truely >> random bits of some key only by a few bits to make it suceptible to >> brute force attacks. > > Note, the proposed RNG contains an unbias operation (the Von-Neumann > unbiaser) which is proven to remove any bias when it is established that > the individual observations are independent. And the way the > observations are generated ensures that they are independent. "Independent" does not mean that your own code avoids reusing data from the previous loop iteration; it means that the _entire_ process that generates the bits is not affected by any memory of the past. The observations are derived from the internal CPU state, which is *not* reset between measurements. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] percpu changes for v3.13-rc1
Hello, Linus.
Two smallish changes for percpu. Two patches to remove unused
this_cpu_xor() and one to fix a bug in percpu init failure path so
that it can reach the proper BUG() instead of oopsing earlier.
The patches are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-3.13
for you to fetch changes up to 90f2492cf9c84fd414ecfd2f40685fb5291a484e:
x86: remove this_cpu_xor() implementation (2013-10-27 09:03:46 -0400)
Thanks.
Heiko Carstens (2):
percpu: remove this_cpu_xor() implementation
x86: remove this_cpu_xor() implementation
Michael Holzheu (1):
percpu: fix bootmem error handling in pcpu_page_first_chunk()
arch/x86/include/asm/percpu.h | 8
include/linux/percpu.h| 32
mm/percpu.c | 5 +++--
3 files changed, 3 insertions(+), 42 deletions(-)
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index 0da5200..604e13d 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -377,9 +377,6 @@ do {
\
#define __this_cpu_or_1(pcp, val) percpu_to_op("or", (pcp), val)
#define __this_cpu_or_2(pcp, val) percpu_to_op("or", (pcp), val)
#define __this_cpu_or_4(pcp, val) percpu_to_op("or", (pcp), val)
-#define __this_cpu_xor_1(pcp, val) percpu_to_op("xor", (pcp), val)
-#define __this_cpu_xor_2(pcp, val) percpu_to_op("xor", (pcp), val)
-#define __this_cpu_xor_4(pcp, val) percpu_to_op("xor", (pcp), val)
#define __this_cpu_xchg_1(pcp, val)percpu_xchg_op(pcp, val)
#define __this_cpu_xchg_2(pcp, val)percpu_xchg_op(pcp, val)
#define __this_cpu_xchg_4(pcp, val)percpu_xchg_op(pcp, val)
@@ -399,9 +396,6 @@ do {
\
#define this_cpu_or_1(pcp, val)percpu_to_op("or", (pcp), val)
#define this_cpu_or_2(pcp, val)percpu_to_op("or", (pcp), val)
#define this_cpu_or_4(pcp, val)percpu_to_op("or", (pcp), val)
-#define this_cpu_xor_1(pcp, val) percpu_to_op("xor", (pcp), val)
-#define this_cpu_xor_2(pcp, val) percpu_to_op("xor", (pcp), val)
-#define this_cpu_xor_4(pcp, val) percpu_to_op("xor", (pcp), val)
#define this_cpu_xchg_1(pcp, nval) percpu_xchg_op(pcp, nval)
#define this_cpu_xchg_2(pcp, nval) percpu_xchg_op(pcp, nval)
#define this_cpu_xchg_4(pcp, nval) percpu_xchg_op(pcp, nval)
@@ -446,7 +440,6 @@ do {
\
#define __this_cpu_add_8(pcp, val) percpu_add_op((pcp), val)
#define __this_cpu_and_8(pcp, val) percpu_to_op("and", (pcp), val)
#define __this_cpu_or_8(pcp, val) percpu_to_op("or", (pcp), val)
-#define __this_cpu_xor_8(pcp, val) percpu_to_op("xor", (pcp), val)
#define __this_cpu_add_return_8(pcp, val) percpu_add_return_op(pcp, val)
#define __this_cpu_xchg_8(pcp, nval) percpu_xchg_op(pcp, nval)
#define __this_cpu_cmpxchg_8(pcp, oval, nval) percpu_cmpxchg_op(pcp, oval,
nval)
@@ -456,7 +449,6 @@ do {
\
#define this_cpu_add_8(pcp, val) percpu_add_op((pcp), val)
#define this_cpu_and_8(pcp, val) percpu_to_op("and", (pcp), val)
#define this_cpu_or_8(pcp, val)percpu_to_op("or", (pcp), val)
-#define this_cpu_xor_8(pcp, val) percpu_to_op("xor", (pcp), val)
#define this_cpu_add_return_8(pcp, val)percpu_add_return_op(pcp, val)
#define this_cpu_xchg_8(pcp, nval) percpu_xchg_op(pcp, nval)
#define this_cpu_cmpxchg_8(pcp, oval, nval)percpu_cmpxchg_op(pcp, oval,
nval)
diff --git a/include/linux/percpu.h b/include/linux/percpu.h
index cc88172..fd6ffe4 100644
--- a/include/linux/percpu.h
+++ b/include/linux/percpu.h
@@ -375,22 +375,6 @@ do {
\
# define this_cpu_or(pcp, val) __pcpu_size_call(this_cpu_or_, (pcp),
(val))
#endif
-#ifndef this_cpu_xor
-# ifndef this_cpu_xor_1
-# define this_cpu_xor_1(pcp, val) _this_cpu_generic_to_op((pcp), (val),
^=)
-# endif
-# ifndef this_cpu_xor_2
-# define this_cpu_xor_2(pcp, val) _this_cpu_generic_to_op((pcp), (val),
^=)
-# endif
-# ifndef this_cpu_xor_4
-# define this_cpu_xor_4(pcp, val) _this_cpu_generic_to_op((pcp), (val),
^=)
-# endif
-# ifndef this_cpu_xor_8
-# define this_cpu_xor_8(pcp, val) _this_cpu_generic_to_op((pcp), (val),
^=)
-# endif
-# define this_cpu_xor(pcp, val)__pcpu_size_call(this_cpu_or_,
(pcp), (val))
-#endif
-
#define _this_cpu_generic_add_return(pcp, val) \
({ \
typeof(pcp) ret__;
Re: ELAN Touchscreen regression in recent 3.12 rc's? (USB)
On Thu, 7 Nov 2013 16:10:07 +0800 AceLan Kao wrote: > Hi Kevin, > > http://people.canonical.com/~acelan/elan_touchscreen/ > Here are the kernels, please test them one by one and tell me which > one works. As your description, the first one should work, and the > second one doesn't, I just want to make sure that, so I build the rc6 > and rc7 kernel to test. Thanks. Thats very nice of you. :) However, I run Fedora rawhide here, so deb's aren't too useful for me. I just confirmed that: kernel-3.12.0-0.rc6.git0.1.fc21.x86_64 is ok. and kernel-3.12.0-0.rc6.git1.1.fc21.x86_64 shows the issue. So, thats between 3.12-rc6 and 57-g69c88dc I'm setting up to build some kernels to bisect it. git bisect start # bad: [69c88dc7d9f1a6c3eceb7058111677c640811c94] vfs: fix new kernel-doc warnings git bisect bad 69c88dc7d9f1a6c3eceb7058111677c640811c94 # good: [31d141e3a666269a3b6fcccddb0351caf7454240] Linux 3.12-rc6 git bisect good 31d141e3a666269a3b6fcccddb0351caf7454240 Will let you know what I end up with, thanks. kevin signature.asc Description: PGP signature
Re: [PATCH] hwmon: add support for GMT G751 chip in lm75 driver
On Sat, 9 Nov 2013 10:27:07 -0800, Guenter Roeck wrote: > On Sat, Nov 09, 2013 at 06:39:14PM +0100, Arnaud Ebalard wrote: > > > > This was tested on a NETGEAR ReadyNAS 2120 device (Marvell Armada XP > > based board, via DT). > > > > Signed-off-by: Arnaud Ebalard > > Looks good. I'll apply it to my -next branch. Since I already sent my > pull request to Linus, this will only go in after -rc1, which I hope > should be ok (unless Jean wants to pick it up for his pull request). No, I don't. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] openrisc: Add DTS and defconfig for DE0-Nano
Add a DTS and defconfig for the Terasic DE0-Nano Development and Education
Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with
support chips and I/O.
The DTS was derived from published versions by Kevin Mehall and Marek
Czerski.
Signed-off-by: Geert Uytterhoeven
Cc: Kevin Mehall
Cc: Marek Czerski
---
Notable changes:
- Change flash0 to spansion,s25sl064p, due to kernel message
m25p80 spi32766.0: found s25sl064p, expected m25p10
- Use reg-shift instead of regstep for i2c0, due to kernel message
ocores-i2c a000.ocores: regstep property deprecated, use reg-shift
arch/openrisc/boot/dts/de0_nano.dts | 158 ++
arch/openrisc/configs/de0_nano_defconfig | 86
2 files changed, 244 insertions(+)
create mode 100644 arch/openrisc/boot/dts/de0_nano.dts
create mode 100644 arch/openrisc/configs/de0_nano_defconfig
diff --git a/arch/openrisc/boot/dts/de0_nano.dts
b/arch/openrisc/boot/dts/de0_nano.dts
new file mode 100644
index ..42f91b5184d9
--- /dev/null
+++ b/arch/openrisc/boot/dts/de0_nano.dts
@@ -0,0 +1,158 @@
+/dts-v1/;
+/ {
+ compatible = "opencores,de0_nano";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <>;
+
+ chosen {
+ bootargs = "console=uart,mmio,0x9000,115200";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x 0x0200>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ compatible = "opencores,or1200-rtlsvn481";
+ reg = <0>;
+ clock-frequency = <5000>;
+ };
+ };
+
+ /*
+* OR1K PIC is built into CPU and accessed via special purpose
+* registers. It is not addressable and, hence, has no 'reg'
+* property.
+*/
+ pic: pic {
+ compatible = "opencores,or1k-pic";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+
+ serial0: serial@9000 {
+ compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
+ reg = <0x9000 0x100>;
+ interrupts = <2>;
+ clock-frequency = <5000>;
+ };
+
+ i2c0: ocores@a000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,i2c-ocores";
+ reg = <0xa000 0x8>;
+ interrupts = <10>;
+ clock-frequency = <5000>;
+
+ reg-shift = <0>;/* 8 bit registers */
+ reg-io-width = <1>; /* 8 bit read/write */
+
+ adxl34x@1d {
+ compatible = "adxl34x";
+ reg = <0x1d>;
+ interrupts = <26>;
+ };
+ eeprom@50 {
+ compatible = "at24,24c02";
+ reg = <0x50>;
+ pagesize = <8>;
+ };
+ };
+
+ spi0: spi0@b000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,spi-simple";
+ reg = <0xb000 0x5>;
+
+ flash0: mtd@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl064p";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+ m25p,fast-read;
+
+ partition@0 {
+ label = "FPGA image";
+ reg = <0x 0x000b>;
+ read-only;
+ };
+ partition@b {
+ label = "bootloader";
+ reg = <0x000b 0x0005>;
+ read-only;
+ };
+ partition@10 {
+ label = "free space";
+ reg = <0x0010 0x0070>;
+ };
+ };
+ };
+
+ spi1: spi1@b100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,spi-simple";
+ reg = <0xb100 0x5>;
+
+ adc@0 {
+ compatible = "adcxx,adcxx8s";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ };
+ };
+
+ gpio0: gpio@9100 {
+ compatible = "opencores,jbtrivial";
+ reg = <0x9100 0x2>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ xlnx,data-offset = <0>;
+ xlnx,tri-offset
[PATCH 1/1] fs: forbid to open anon-inode files via /proc
open("/proc/pid/$anon-fd") should fail, we can't create the new
file with correctly. Currently this creates the bogus file with
->f_op == empty_fops copied from ->i_fop, this is harmless but
still wrong and misleading.
Now that anon_inode_fops has gone away we can add empty_no_open()
to disallow this. This affects anon_inode_getfile() and the new
aio_private_file().
Signed-off-by: Oleg Nesterov
---
fs/inode.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 4bcdad3..b7c159c 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -114,6 +114,11 @@ int proc_nr_inodes(ctl_table *table, int write,
}
#endif
+static int empty_no_open(struct inode *inode, struct file *file)
+{
+ return -ENXIO;
+}
+
/**
* inode_init_always - perform inode structure intialisation
* @sb: superblock inode belongs to
@@ -124,8 +129,10 @@ int proc_nr_inodes(ctl_table *table, int write,
*/
int inode_init_always(struct super_block *sb, struct inode *inode)
{
+ static const struct file_operations empty_fops = {
+ .open = empty_no_open,
+ };
static const struct inode_operations empty_iops;
- static const struct file_operations empty_fops;
struct address_space *const mapping = >i_data;
inode->i_sb = sb;
--
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/
[PATCH 0/1] fs: forbid to open anon-inode files via /proc
On 11/08, Oleg Nesterov wrote:
>
> On 11/08, Oleg Nesterov wrote:
> >
> > On 11/08, Stephen Rothwell wrote:
> > >
> > > Hi Andrew,
> > >
> > > Today's linux-next merge of the akpm-current tree got a conflict in
> > > fs/anon_inodes.c between commit 24b0303e9532 ("take anon inode allocation
> > > to libfs.c") from the vfs tree and commit 02f3ac4386d9 ("anon_inodefs:
> > > forbid open via /proc") from the akpm-current tree.
> > >
> > > I just dropped the akpm-current changes for today - they should probably
> > > be applied to fs/libfs.c.
> >
> > Well, this probably means that
> >
> > anon_inodefs-forbid-open-via-proc.patch
> >
> > should be dropped. I'll rediff this patch against vfs.git
>
> 24b0303e9532 also removes anon_inode_fops. It seems that it was not really
> needed anyway, inode_init_always() does inode->i_fop = empty_fops...
>
> So probably we can simply change empty_fops but I need to recheck.
Well. It looks "really obvious" that any user of inode_init_always()
either needs to change ->i_fop or this file should not be opened via
/proc...
So, Al, feel free to ignore, this is minor. Still I think this patch
makes sense. Based on vfs.git#for-next.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: mv643xx_eth: take over maintainership from Lennart
From: Jason Cooper Date: Fri, 4 Oct 2013 09:07:07 -0400 > On Fri, Oct 04, 2013 at 12:56:39PM +0200, Sebastian Hesselbarth wrote: >> Lennart says: "I haven't been able to spend time on mv643xx_eth for a >> while now, so if you want to take over maintainership, I'd be fine with >> that." >> >> Signed-off-by: Sebastian Hesselbarth >> Acked-by: Lennert Buytenhek >> --- >> TBH, I have no clue about netdev internals, yet. But if David and Jason >> Cooper promise to have one eye each on the first Acks, I am willing to >> take over maintainership. > > If David is ok with it, > > Acked-by: Jason Cooper This got lost in the noise because it didn't get sent to netdev, I've applied it now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hwmon: add support for GMT G751 chip in lm75 driver
Hi Guenter, Guenter Roeck writes: > On Sat, Nov 09, 2013 at 06:39:14PM +0100, Arnaud Ebalard wrote: >> >> This was tested on a NETGEAR ReadyNAS 2120 device (Marvell Armada XP >> based board, via DT). >> >> Signed-off-by: Arnaud Ebalard > > Looks good. I'll apply it to my -next branch. Since I already sent my > pull request to Linus, this will only go in after -rc1, which I hope > should be ok (unless Jean wants to pick it up for his pull request). Perfect, thanks. >> --- >> Hi Guenter, >> >> As a side note, I removed the hunk that was present in previous patch to >> add gmt to the list of DT vendor prefixes because I noticed someone had >> taken care: https://lkml.org/lkml/2013/9/12/365 >> >> For the records, here is what I get on my NAS with the attached patch: >> >> root@thin:/sys# sensors >> g762-i2c-0-3e >> Adapter: mv64xxx_i2c adapter >> fan1:5461 RPM (div = 1) >> >> g762-i2c-0-48 >> Adapter: mv64xxx_i2c adapter >> fan1:5461 RPM (div = 1) >> >> g762-i2c-0-49 >> Adapter: mv64xxx_i2c adapter >> fan1:5461 RPM (div = 1) >> > Those rpms are pretty high. Are the fans all really running that fast ? Unlike the fans on NETGEAR ReadyNAS 102 and 104 which are Protechnic MGT9212YB-025 92mmx92mm running at 3200 RPM max, the three fans in the RN2120 are Protechnic MGT4012XB-O20, i.e. 40mmx40mm running at 8000 RPM max. At least, this is the max RPM value I found on their website (Search Products on left side of http://www.protechnic-us.com/en/) for both devices. When pushing one a bit, here is the max rotation speed I get: root@thin:/sys/bus/i2c/drivers/g762/0-003e# echo 9000 > fan1_target ; \ sleep 5 ; cat fan1_input 8057 which AFAICT validates current settings for G762 and fan combination. Did I miss something? Cheers, a+ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] fuzz tested 32 bit user mode linux image hangs in radix_tree_next_chunk()
Am 09.11.2013 20:07, schrieb Toralf Förster: > On 11/06/2013 10:31 PM, Richard Weinberger wrote: >> Am 06.11.2013 22:18, schrieb Toralf Förster: >>> On 11/06/2013 05:06 PM, Konstantin Khlebnikov wrote: In this case it must stop after scanning whole tree in line: /* Overflow after ~0UL */ if (!index) return NULL; >>> >>> A fresh current example with latest git tree shows that lines 769 and 770 >>> do alternate : >> >> Can you please ask gdb for the value of offset? >> >> Thanks, >> //richard >> > > Still trying to get those values. One attempt to do that was to replace -O2 > with -O0 in the Makefile, > but that resulted into this error : > > LD kernel/built-in.o > CC mm/memory.o > In function ‘zap_pmd_range’, > inlined from ‘zap_pud_range’ at mm/memory.c:1265:8, > inlined from ‘unmap_page_range’ at mm/memory.c:1290:8: > mm/memory.c:1220:23: error: call to ‘__compiletime_assert_1220’ declared with > attribute error: BUILD_BUG failed > mm/memory.c: In function ‘follow_page_mask’: > mm/memory.c:1530:18: error: call to ‘__compiletime_assert_1530’ declared with > attribute error: BUILD_BUG failed > make[1]: *** [mm/memory.o] Error 1 > make: *** [mm] Error 2 > > > With -O1 it compiled at least. You cannot build Linux with -O1/O0. Try printing the value using printk... Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/24] mm/power: Use memblock apis for early memory allocations
On Friday 08 November 2013 08:30 PM, Rafael J. Wysocki wrote: > On Friday, November 08, 2013 06:41:49 PM Santosh Shilimkar wrote: >> Switch to memblock interfaces for early memory allocator instead of >> bootmem allocator. No functional change in beahvior than what it is >> in current code from bootmem users points of view. >> >> Archs already converted to NO_BOOTMEM now directly use memblock >> interfaces instead of bootmem wrappers build on top of memblock. And the >> archs which still uses bootmem, these new apis just fallback to exiting >> bootmem APIs. >> >> Cc: Yinghai Lu >> Cc: Tejun Heo >> Cc: Andrew Morton >> Cc: Pavel Machek >> Cc: "Rafael J. Wysocki" >> Cc: linux...@vger.kernel.org >> >> Signed-off-by: Santosh Shilimkar > > Fine by me, thanks! > Thanks Rafael. I take that as an ack. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 14/24] mm/lib/swiotlb: Use memblock apis for early memory allocations
On Saturday 09 November 2013 11:55 AM, Konrad Rzeszutek Wilk wrote: > Santosh Shilimkar wrote: >> Switch to memblock interfaces for early memory allocator instead of >> bootmem allocator. No functional change in beahvior than what it is >> in current code from bootmem users points of view. >> >> Archs already converted to NO_BOOTMEM now directly use memblock >> interfaces instead of bootmem wrappers build on top of memblock. And >> the >> archs which still uses bootmem, these new apis just fallback to exiting >> bootmem APIs. >> >> Cc: Yinghai Lu >> Cc: Tejun Heo >> Cc: Andrew Morton >> Cc: Konrad Rzeszutek Wilk >> >> Signed-off-by: Santosh Shilimkar >> --- >> lib/swiotlb.c | 36 +--- >> 1 file changed, 21 insertions(+), 15 deletions(-) >> >> diff --git a/lib/swiotlb.c b/lib/swiotlb.c >> index 4e8686c..78ac01a 100644 >> --- a/lib/swiotlb.c >> +++ b/lib/swiotlb.c >> @@ -169,8 +169,9 @@ int __init swiotlb_init_with_tbl(char *tlb, >> unsigned long nslabs, int verbose) >> /* >> * Get the overflow emergency buffer >> */ >> -v_overflow_buffer = alloc_bootmem_low_pages_nopanic( >> -PAGE_ALIGN(io_tlb_overflow)); >> +v_overflow_buffer = memblock_virt_alloc_align_nopanic( >> +PAGE_ALIGN(io_tlb_overflow), >> +PAGE_SIZE); > > Does this guarantee that the pages will be allocated below 4GB? > Yes. The memblock layer still allocates memory from lowmem. As I mentioned, there is no change in the behavior than what is today apart from just the interface change. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [uml-devel] fuzz tested 32 bit user mode linux image hangs in radix_tree_next_chunk()
On 11/06/2013 10:31 PM, Richard Weinberger wrote:
> Am 06.11.2013 22:18, schrieb Toralf Förster:
>> On 11/06/2013 05:06 PM, Konstantin Khlebnikov wrote:
>>> In this case it must stop after scanning whole tree in line:
>>> /* Overflow after ~0UL */
>>> if (!index)
>>> return NULL;
>>>
>>
>> A fresh current example with latest git tree shows that lines 769 and 770 do
>> alternate :
>
> Can you please ask gdb for the value of offset?
>
> Thanks,
> //richard
>
Still trying to get those values. One attempt to do that was to replace -O2
with -O0 in the Makefile,
but that resulted into this error :
LD kernel/built-in.o
CC mm/memory.o
In function ‘zap_pmd_range’,
inlined from ‘zap_pud_range’ at mm/memory.c:1265:8,
inlined from ‘unmap_page_range’ at mm/memory.c:1290:8:
mm/memory.c:1220:23: error: call to ‘__compiletime_assert_1220’ declared with
attribute error: BUILD_BUG failed
mm/memory.c: In function ‘follow_page_mask’:
mm/memory.c:1530:18: error: call to ‘__compiletime_assert_1530’ declared with
attribute error: BUILD_BUG failed
make[1]: *** [mm/memory.o] Error 1
make: *** [mm] Error 2
With -O1 it compiled at least.
>>
>> tfoerste@n22 ~/devel/linux $ sudo gdb /usr/local/bin/linux-v3.12-48-gbe408cd
>> 16619 -n -batch -ex bt
>> 0x08296a8c in radix_tree_next_chunk (root=0x25, iter=0x462e7c64, flags=12)
>> at lib/radix-tree.c:770
>> 770 if (node->slots[offset])
>> #0 0x08296a8c in radix_tree_next_chunk (root=0x25, iter=0x462e7c64,
>> flags=12) at lib/radix-tree.c:770
>> #1 0x080cc1fe in find_get_pages (mapping=0x462ad470, start=0, nr_pages=14,
>> pages=0xc) at mm/filemap.c:844
>> #2 0x080d5d6a in pagevec_lookup (pvec=0x462e7cc8, mapping=0x25, start=37,
>> nr_pages=37) at mm/swap.c:914
>> #3 0x080d615a in truncate_inode_pages_range (mapping=0x462ad470, lstart=0,
>> lend=-1) at mm/truncate.c:241
>> #4 0x080d64ff in truncate_inode_pages (mapping=0x25, lstart=51539607589) at
>> mm/truncate.c:358
>>
>>
>>
>>
>> tfoerste@n22 ~/devel/linux $ sudo gdb /usr/local/bin/linux-v3.12-48-gbe408cd
>> 16619 -n -batch -ex bt
>> radix_tree_next_chunk (root=0x28, iter=0x462e7c64, flags=18) at
>> lib/radix-tree.c:769
>> 769 while (++offset <
>> RADIX_TREE_MAP_SIZE) {
>> #0 radix_tree_next_chunk (root=0x28, iter=0x462e7c64, flags=18) at
>> lib/radix-tree.c:769
>> #1 0x080cc1fe in find_get_pages (mapping=0x462ad470, start=0, nr_pages=14,
>> pages=0x12) at mm/filemap.c:844
>> #2 0x080d5d6a in pagevec_lookup (pvec=0x462e7cc8, mapping=0x28, start=40,
>> nr_pages=40) at mm/swap.c:914
>> #3 0x080d615a in truncate_inode_pages_range (mapping=0x462ad470, lstart=0,
>> lend=-1) at mm/truncate.c:241
>> #4 0x080d64ff in truncate_inode_pages (mapping=0x28, lstart=77309411368) at
>> mm/truncate.c:358
>> #5 0x0825e388 in hostfs_evict_inode (inode=0x462ad3b8) at
>> fs/hostfs/hostfs_kern.c:242
>> #6 0x0811a8df in evict (inode=0x462ad3b8) at fs/inode.c:549
>>
>>
>
>
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regmap: Fix compile warning with value uninitialized
2013-11-09 19:57 keltezéssel, Mark Brown írta: > On Sat, Nov 09, 2013 at 04:34:07PM +0100, Levente Kurusa wrote: >> 2013-11-09 16:16 keltezéssel, Mark Brown írta: > - int i, ret; + int i; + int ret = 0; bool bypass; > >> Wouldn't the following be better? > >> int i, ret = 0; > >> I think it is more readable. > > No, that's not the kernel coding style. Alright. > >>> This sort of fix isn't ideal, it just silences the warning but if the >>> compiler has spotted a genuine oversight in the function it won't >>> address it. It's better to include some analysis of why this is a good >>> fix. > >> The only condition when 'ret' is not set is when the num_regs parameter is >> zero >> and krealloc doesn't fail. If the above two conditions apply, then >> the code would return an uninitialized value. However, calling this function >> with >> num_regs == 0, would be a waste as it essentially does nothing. > > OK, so that should be in the changelog - or there should be an error > check for num_regs == 0 which might be more helpful. Adding an explanation into the changelog and editing the patch in a way so that it adds a check would be the best choice I think. Cai, can you please do this as part of the patch? -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] uprobes: Cleanup !CONFIG_UPROBES decls, unexport xol_area
1. Don't include asm/uprobes.h unconditionally, we only need
it if CONFIG_UPROBES.
2. Move the definition of "struct xol_area" into uprobes.c.
Perhaps we should simply kill struct uprobes_state, it buys
nothing.
3. Kill the dummy definition of uprobe_get_swbp_addr(), nobody
except handle_swbp() needs it.
4. Purely cosmetic, but move the decl of uprobe_get_swbp_addr()
up, close to other __weak helpers.
Signed-off-by: Oleg Nesterov
---
include/linux/uprobes.h | 31 ---
kernel/events/uprobes.c | 19 +++
2 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 366b8b2..fe0c0bb 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -33,10 +33,6 @@ struct mm_struct;
struct inode;
struct notifier_block;
-#ifdef CONFIG_ARCH_SUPPORTS_UPROBES
-# include
-#endif
-
#define UPROBE_HANDLER_REMOVE 1
#define UPROBE_HANDLER_MASK1
@@ -61,6 +57,8 @@ struct uprobe_consumer {
};
#ifdef CONFIG_UPROBES
+#include
+
enum uprobe_task_state {
UTASK_RUNNING,
UTASK_SSTEP,
@@ -93,24 +91,7 @@ struct uprobe_task {
unsigned intdepth;
};
-/*
- * On a breakpoint hit, thread contests for a slot. It frees the
- * slot after singlestep. Currently a fixed number of slots are
- * allocated.
- */
-struct xol_area {
- wait_queue_head_t wq; /* if all slots are busy */
- atomic_tslot_count; /* number of in-use slots */
- unsigned long *bitmap;/* 0 = free slot */
- struct page *page;
-
- /*
-* We keep the vma's vm_start rather than a pointer to the vma
-* itself. The probed process or a naughty kernel module could make
-* the vma go away, and we must handle that reasonably gracefully.
-*/
- unsigned long vaddr; /* Page(s) of instruction slots
*/
-};
+struct xol_area;
struct uprobes_state {
struct xol_area *xol_area;
@@ -120,6 +101,7 @@ extern int __weak set_swbp(struct arch_uprobe *aup, struct
mm_struct *mm, unsign
extern int __weak set_orig_insn(struct arch_uprobe *aup, struct mm_struct *mm,
unsigned long vaddr);
extern bool __weak is_swbp_insn(uprobe_opcode_t *insn);
extern bool __weak is_trap_insn(uprobe_opcode_t *insn);
+extern unsigned long __weak uprobe_get_swbp_addr(struct pt_regs *regs);
extern int uprobe_write_opcode(struct mm_struct *mm, unsigned long vaddr,
uprobe_opcode_t);
extern int uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
extern int uprobe_apply(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc, bool);
@@ -131,7 +113,6 @@ extern void uprobe_end_dup_mmap(void);
extern void uprobe_dup_mmap(struct mm_struct *oldmm, struct mm_struct *newmm);
extern void uprobe_free_utask(struct task_struct *t);
extern void uprobe_copy_process(struct task_struct *t, unsigned long flags);
-extern unsigned long __weak uprobe_get_swbp_addr(struct pt_regs *regs);
extern int uprobe_post_sstep_notifier(struct pt_regs *regs);
extern int uprobe_pre_sstep_notifier(struct pt_regs *regs);
extern void uprobe_notify_resume(struct pt_regs *regs);
@@ -187,10 +168,6 @@ static inline bool uprobe_deny_signal(void)
{
return false;
}
-static inline unsigned long uprobe_get_swbp_addr(struct pt_regs *regs)
-{
- return 0;
-}
static inline void uprobe_free_utask(struct task_struct *t)
{
}
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index acc0317..a7239eb 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -86,6 +86,25 @@ struct return_instance {
};
/*
+ * On a breakpoint hit, thread contests for a slot. It frees the
+ * slot after singlestep. Currently a fixed number of slots are
+ * allocated.
+ */
+struct xol_area {
+ wait_queue_head_t wq; /* if all slots are busy */
+ atomic_tslot_count; /* number of in-use slots */
+ unsigned long *bitmap;/* 0 = free slot */
+ struct page *page;
+
+ /*
+* We keep the vma's vm_start rather than a pointer to the vma
+* itself. The probed process or a naughty kernel module could make
+* the vma go away, and we must handle that reasonably gracefully.
+*/
+ unsigned long vaddr; /* Page(s) of instruction slots
*/
+};
+
+/*
* valid_vma: Verify if the specified vma is an executable vma
* Relax restrictions while unregistering: vm_flags might have
* changed after breakpoint was inserted.
--
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: [PATCH] regmap: Fix compile warning with value uninitialized
On Sat, Nov 09, 2013 at 04:34:07PM +0100, Levente Kurusa wrote: > 2013-11-09 16:16 keltezéssel, Mark Brown írta: > >> - int i, ret; > >> + int i; > >> + int ret = 0; > >>bool bypass; > Wouldn't the following be better? > int i, ret = 0; > I think it is more readable. No, that's not the kernel coding style. > > This sort of fix isn't ideal, it just silences the warning but if the > > compiler has spotted a genuine oversight in the function it won't > > address it. It's better to include some analysis of why this is a good > > fix. > The only condition when 'ret' is not set is when the num_regs parameter is > zero > and krealloc doesn't fail. If the above two conditions apply, then > the code would return an uninitialized value. However, calling this function > with > num_regs == 0, would be a waste as it essentially does nothing. OK, so that should be in the changelog - or there should be an error check for num_regs == 0 which might be more helpful. > Also, I think code which throws warnings is worse than code > which doesn't. Right, but code that is behaves incorrectly is worse still. We need to be careful that when changing the code to remove warnings we make sure that we fix any real problems the compiler was warning us about. signature.asc Description: Digital signature
Re: [RFC] ASoC: Add support for BCM2835
On Fri, Nov 08, 2013 at 09:56:51PM +0100, Florian Meier wrote:
This all looks pretty good, a few comments belown but nothing terribly
substantial.
> source "sound/soc/atmel/Kconfig"
> source "sound/soc/au1x/Kconfig"
> +source "sound/soc/bcm2835/Kconfig"
Is this really only used on this one SoC - I'd expect a more generic
name for the directory?
> + /*
> + * Clear both FIFOs if the one that should be started
> + * is not empty at the moment. This should only happen
> + * after overrun. Otherwise, hw_params would have cleared
> + * the FIFO.
> + */
> + regmap_read(dev->i2s_regmap, BCM2835_I2S_CS_A_REG, _reg);
> +
> + switch (substream->stream) {
> + case SNDRV_PCM_STREAM_PLAYBACK:
> + if (cs_reg & BCM2835_I2S_TXE)
> + break;
> + case SNDRV_PCM_STREAM_CAPTURE:
> + if (!(cs_reg & BCM2835_I2S_RXD))
> + break;
> +
> + bcm2835_i2s_clear_fifos(dev);
> + }
This is a bit confusing to me - the switch statement with fallthroughs
is a fairly unusual idiom and the placement of the clear is a bit
peculiar. Writing it out with ifs would probably make it clearer what
the intent is. It's also not clear why we're doing this or that it's
safe, won't this have a destructive effect on the other stream?
> + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
> + regmap_update_bits(dev->i2s_regmap, BCM2835_I2S_CS_A_REG,
> + BCM2835_I2S_RXON, 0);
> + } else {
> + regmap_update_bits(dev->i2s_regmap, BCM2835_I2S_CS_A_REG,
> + BCM2835_I2S_TXON, 0);
> + }
> +
No { } for single statement if conditions.
> +static int bcm2835_i2s_dai_probe(struct snd_soc_dai *dai)
> +{
> + struct bcm2835_i2s_dev *dev = snd_soc_dai_get_drvdata(dai);
> +
> + /* Set the appropriate DMA parameters */
> + dev->dma_data[SNDRV_PCM_STREAM_PLAYBACK].addr =
> + (dma_addr_t)BCM2835_I2S_FIFO_PHYSICAL_ADDR;
> + dev->dma_data[SNDRV_PCM_STREAM_CAPTURE].addr =
> + (dma_addr_t)BCM2835_I2S_FIFO_PHYSICAL_ADDR;
DT?
> +static bool bcm2835_clk_precious_reg(struct device *dev, unsigned int reg)
> +{
> + return false;
> +}
Just omit this, it's the default.
> +static const struct regmap_config bcm2835_i2s_regmap_config = {
> +};
There should be something in here.
> + ioarea = devm_request_mem_region(>dev, mem->start,
> +resource_size(mem),
> +pdev->name);
> + if (!ioarea) {
> + dev_err(>dev, "I2S probe: Memory region already
> claimed.\n");
> + return -EBUSY;
> + }
> +
> + base = devm_ioremap(>dev, mem->start,
> + resource_size(mem));
devm_ioremap_resource(). Thinking about this we should probably have a
regmap MMIO constructor that takes a resource...
> +static const struct snd_pcm_hardware bcm2835_pcm_hardware = {
> + .info = SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_MMAP_VALID |
> + SNDRV_PCM_INFO_INTERLEAVED |
> + SNDRV_PCM_INFO_JOINT_DUPLEX,
> + .formats= SNDRV_PCM_FMTBIT_S16_LE |
> + SNDRV_PCM_FMTBIT_S32_LE,
> + .period_bytes_min = 32,
> + .period_bytes_max = 64 * PAGE_SIZE,
> + .periods_min= 2,
> + .periods_max= 255,
> + .buffer_bytes_max = 128 * PAGE_SIZE,
The dmaengine code recently acquired the ability to work out most of
this automatically by querying the DMA controller, you should use that
as much as possible.
signature.asc
Description: Digital signature
Re: [PATCH] hwmon: add support for GMT G751 chip in lm75 driver
On Sat, Nov 09, 2013 at 06:39:14PM +0100, Arnaud Ebalard wrote: > > This was tested on a NETGEAR ReadyNAS 2120 device (Marvell Armada XP > based board, via DT). > > Signed-off-by: Arnaud Ebalard Looks good. I'll apply it to my -next branch. Since I already sent my pull request to Linus, this will only go in after -rc1, which I hope should be ok (unless Jean wants to pick it up for his pull request). > --- > Hi Guenter, > > As a side note, I removed the hunk that was present in previous patch to > add gmt to the list of DT vendor prefixes because I noticed someone had > taken care: https://lkml.org/lkml/2013/9/12/365 > > For the records, here is what I get on my NAS with the attached patch: > > root@thin:/sys# sensors > g762-i2c-0-3e > Adapter: mv64xxx_i2c adapter > fan1:5461 RPM (div = 1) > > g762-i2c-0-48 > Adapter: mv64xxx_i2c adapter > fan1:5461 RPM (div = 1) > > g762-i2c-0-49 > Adapter: mv64xxx_i2c adapter > fan1:5461 RPM (div = 1) > Those rpms are pretty high. Are the fans all really running that fast ? Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: mei: cancel stall timers in mei_reset
Hi, >Looks like there is a hiccup in scheduling during resume and timer work is >kicked before its time and starts unnecessary the reset flow. >Can you check that the device is in good state (/mei/devastate , it >should be ENABLED). Yes, /sys/kernel/debug/mei/devstate contains "ENABLED" (checked on kernel 3.10.15 I built with schedule_...() commented out). >We will work on some solution. Thanks! Regards, Eugene -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Matt Sealey writes: > BTW has there been any evaluation of the penalty for the extra > branching, or the performance hit for the ARMv7-without-division > cases? The branches themselves probably have minimal overhead. There will however be code to preserve call-clobbered registers (and move the values to/from r0/r1) that would not be needed if the div instructions were done inline (obviously such a kernel could only run on hardware with division support). -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] uprobes/powerpc: Kill arch_uprobe->ainsn
powerpc has both arch_uprobe->insn and arch_uprobe->ainsn to
make the generic code happy. This is no longer needed after
the previous change, powerpc can just use "u32 insn".
Signed-off-by: Oleg Nesterov
---
arch/powerpc/include/asm/uprobes.h |5 ++---
arch/powerpc/kernel/uprobes.c |2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/uprobes.h
b/arch/powerpc/include/asm/uprobes.h
index 75c6ecd..7422a99 100644
--- a/arch/powerpc/include/asm/uprobes.h
+++ b/arch/powerpc/include/asm/uprobes.h
@@ -36,9 +36,8 @@ typedef ppc_opcode_t uprobe_opcode_t;
struct arch_uprobe {
union {
- u8 insn[MAX_UINSN_BYTES];
- u8 ixol[MAX_UINSN_BYTES];
- u32 ainsn;
+ u32 insn;
+ u32 ixol;
};
};
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index 59f419b..003b209 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -186,7 +186,7 @@ bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe,
struct pt_regs *regs)
* emulate_step() returns 1 if the insn was successfully emulated.
* For all other cases, we need to single-step in hardware.
*/
- ret = emulate_step(regs, auprobe->ainsn);
+ ret = emulate_step(regs, auprobe->insn);
if (ret > 0)
return true;
--
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/
[PATCH 1/2] uprobes: Don't assume that arch_uprobe->insn/ixol is u8[MAX_UINSN_BYTES]
arch_uprobe should be opaque as much as possible to the generic
code, but currently it assumes that insn/ixol must be u8[] of the
known size. Remove this unnecessary dependency, we can use "&" and
and sizeof() with the same effect.
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 2546a7b..acc0317 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -330,7 +330,7 @@ int __weak set_swbp(struct arch_uprobe *auprobe, struct
mm_struct *mm, unsigned
int __weak
set_orig_insn(struct arch_uprobe *auprobe, struct mm_struct *mm, unsigned long
vaddr)
{
- return uprobe_write_opcode(mm, vaddr, *(uprobe_opcode_t
*)auprobe->insn);
+ return uprobe_write_opcode(mm, vaddr, *(uprobe_opcode_t
*)>insn);
}
static int match_uprobe(struct uprobe *l, struct uprobe *r)
@@ -529,8 +529,8 @@ static int copy_insn(struct uprobe *uprobe, struct file
*filp)
{
struct address_space *mapping = uprobe->inode->i_mapping;
loff_t offs = uprobe->offset;
- void *insn = uprobe->arch.insn;
- int size = MAX_UINSN_BYTES;
+ void *insn = >arch.insn;
+ int size = sizeof(uprobe->arch.insn);
int len, err = -EIO;
/* Copy only available bytes, -EIO if nothing was read */
@@ -569,7 +569,7 @@ static int prepare_uprobe(struct uprobe *uprobe, struct
file *file,
goto out;
ret = -ENOTSUPP;
- if (is_trap_insn((uprobe_opcode_t *)uprobe->arch.insn))
+ if (is_trap_insn((uprobe_opcode_t *)>arch.insn))
goto out;
ret = arch_uprobe_analyze_insn(>arch, mm, vaddr);
@@ -1264,7 +1264,7 @@ static unsigned long xol_get_insn_slot(struct uprobe
*uprobe)
/* Initialize the slot */
copy_to_page(area->page, xol_vaddr,
- uprobe->arch.ixol, sizeof(uprobe->arch.ixol));
+ >arch.ixol, sizeof(uprobe->arch.ixol));
/*
* We probably need flush_icache_user_range() but it needs vma.
* This should work on supported architectures too.
--
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/
[PATCH 0/2] uprobes: typeof(arch_uprobe->insn) cleanups
Hello. Ananth, could you please explicitly ack or nack 2/2 ? It is really simple, but obviously I can't test it. And even if it is correct it should be merged only if you like it, this is the minor cleanup. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hwmon: (coretemp) Refine TjMax detection
Intel's turbostat code uses only 7 bits from MSR_IA32_TEMPERATURE_TARGET to
read TjMax, and also only accepts it if the reported temperature is at least
85 degrees C. Play safe and do the same.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/coretemp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index cde4e47..310ce19 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -368,12 +368,12 @@ static int get_tjmax(struct cpuinfo_x86 *c, u32 id,
struct device *dev)
if (cpu_has_tjmax(c))
dev_warn(dev, "Unable to read TjMax from CPU %u\n", id);
} else {
- val = (eax >> 16) & 0xff;
+ val = (eax >> 16) & 0x7f;
/*
* If the TjMax is not plausible, an assumption
* will be used
*/
- if (val) {
+ if (val >= 85) {
dev_dbg(dev, "TjMax is %d degrees C\n", val);
return val * 1000;
}
--
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/
[PATCH 1/3] hwmon: (coretemp) Use PCI host bridge ID to identify CPU if necessary
Atom S12x0 CPUs are identified by the CPU host bridge ID. Add an override
table based on PCI IDs as well as code to detect it.
PCI access functions can now be called with PCI disabled, so unlike previous
attempts to use PCI IDs, the code no longer depends on it. If PCI is disabled,
the CPU will not be identified correctly. Since it is unlikely that anything
will work in this case, this is an acceptable limitation.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/coretemp.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 78be661..5c8ab25 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -190,6 +191,17 @@ static ssize_t show_temp(struct device *dev,
return tdata->valid ? sprintf(buf, "%d\n", tdata->temp) : -EAGAIN;
}
+struct tjmax_pci {
+ unsigned int device;
+ int tjmax;
+};
+
+static const struct tjmax_pci tjmax_pci_table[] __cpuinitconst = {
+ { 0x0c72, 102000 }, /* Atom S1240 (Centerton) */
+ { 0x0c73, 95000 }, /* Atom S1220 (Centerton) */
+ { 0x0c75, 95000 }, /* Atom S1260 (Centerton) */
+};
+
struct tjmax {
char const *id;
int tjmax;
@@ -222,8 +234,11 @@ static const struct tjmax_model tjmax_model_table[] = {
* is undetectable by software
*/
{ 0x27, ANY, 9 }, /* Atom Medfield (Z2460) */
- { 0x35, ANY, 9 }, /* Atom Clover Trail/Cloverview (Z2760) */
- { 0x36, ANY, 10 }, /* Atom Cedar Trail/Cedarview (N2xxx, D2xxx) */
+ { 0x35, ANY, 9 }, /* Atom Clover Trail/Cloverview (Z27x0) */
+ { 0x36, ANY, 10 }, /* Atom Cedar Trail/Cedarview (N2xxx, D2xxx)
+* Also matches S12x0 (stepping 9), covered by
+* PCI table
+*/
};
static int adjust_tjmax(struct cpuinfo_x86 *c, u32 id, struct device *dev)
@@ -236,8 +251,20 @@ static int adjust_tjmax(struct cpuinfo_x86 *c, u32 id,
struct device *dev)
int err;
u32 eax, edx;
int i;
+ struct pci_dev *host_bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+
+ /*
+* Explicit tjmax table entries override heuristics.
+* First try PCI host bridge IDs, followed by model ID strings
+* and model/stepping information.
+*/
+ if (host_bridge && host_bridge->vendor == PCI_VENDOR_ID_INTEL) {
+ for (i = 0; i < ARRAY_SIZE(tjmax_pci_table); i++) {
+ if (host_bridge->device == tjmax_pci_table[i].device)
+ return tjmax_pci_table[i].tjmax;
+ }
+ }
- /* explicit tjmax table entries override heuristics */
for (i = 0; i < ARRAY_SIZE(tjmax_table); i++) {
if (strstr(c->x86_model_id, tjmax_table[i].id))
return tjmax_table[i].tjmax;
--
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/
[PATCH 2/3] hwmon: (coretemp) Add PCI device ID for CE41x0 CPUs
Since we now have to use PCI IDs to detect CPU types anyway, use this mechanism
to detect CE41x0 CPUs. Advantage is that it only requires a single entry and
covers all variants of CE41x0, including those unknown to us.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/coretemp.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 5c8ab25..cde4e47 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -197,6 +197,7 @@ struct tjmax_pci {
};
static const struct tjmax_pci tjmax_pci_table[] __cpuinitconst = {
+ { 0x0708, 11 }, /* CE41x0 (Sodaville ) */
{ 0x0c72, 102000 }, /* Atom S1240 (Centerton) */
{ 0x0c73, 95000 }, /* Atom S1220 (Centerton) */
{ 0x0c75, 95000 }, /* Atom S1260 (Centerton) */
@@ -210,9 +211,6 @@ struct tjmax {
static const struct tjmax tjmax_table[] = {
{ "CPU 230", 10 }, /* Model 0x1c, stepping 2 */
{ "CPU 330", 125000 }, /* Model 0x1c, stepping 2 */
- { "CPU CE4110", 11 }, /* Model 0x1c, stepping 10 Sodaville */
- { "CPU CE4150", 11 }, /* Model 0x1c, stepping 10 */
- { "CPU CE4170", 11 }, /* Model 0x1c, stepping 10 */
};
struct tjmax_model {
--
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/
[PATCH] hwmon: add support for GMT G751 chip in lm75 driver
This was tested on a NETGEAR ReadyNAS 2120 device (Marvell Armada XP
based board, via DT).
Signed-off-by: Arnaud Ebalard
---
Hi Guenter,
As a side note, I removed the hunk that was present in previous patch to
add gmt to the list of DT vendor prefixes because I noticed someone had
taken care: https://lkml.org/lkml/2013/9/12/365
For the records, here is what I get on my NAS with the attached patch:
root@thin:/sys# sensors
g762-i2c-0-3e
Adapter: mv64xxx_i2c adapter
fan1:5461 RPM (div = 1)
g762-i2c-0-48
Adapter: mv64xxx_i2c adapter
fan1:5461 RPM (div = 1)
g762-i2c-0-49
Adapter: mv64xxx_i2c adapter
fan1:5461 RPM (div = 1)
g751-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1:+30.5°C (high = +80.0°C, hyst = +75.0°C)
armada_thermal-virtual-0
Adapter: Virtual device
temp1:+34.2°C
root@thin:/sys/bus/i2c/drivers/lm75/0-004c# ls
driver modalias subsystemtemp1_max uevent
hwmon name temp1_input temp1_max_hyst
root@thin:/sys/bus/i2c/drivers/lm75/0-004c# dmesg | grep lm
[ 120.960471] lm75 0-004c: hwmon3: sensor 'g751'
just by adding the following to the .dts:
g751: g751@4c {
compatible = "gmt,g751";
reg = <0x4c>;
};
Do not hesitate to tell me if I missed something.
Cheers,
a+
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
drivers/hwmon/Kconfig | 1 +
drivers/hwmon/lm75.c | 3 +++
3 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index ad6a738..c98e5a2 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -35,6 +35,7 @@ fsl,mc13892 MC13892: Power Management Integrated
Circuit (PMIC) for i.MX35/51
fsl,mma8450MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic
Accelerometer
fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
+gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog
with Two-Wire Interface
infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max
100khz)
infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz)
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index b3ab9d4..52d548f 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -656,6 +656,7 @@ config SENSORS_LM75
- Analog Devices ADT75
- Dallas Semiconductor DS75, DS1775 and DS7505
+ - Global Mixed-mode Technology (GMT) G751
- Maxim MAX6625 and MAX6626
- Microchip MCP980x
- National Semiconductor LM75, LM75A
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..7e3ef13 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -39,6 +39,7 @@ enum lm75_type { /* keep sorted in alphabetical
order */
ds1775,
ds75,
ds7505,
+ g751,
lm75,
lm75a,
max6625,
@@ -208,6 +209,7 @@ lm75_probe(struct i2c_client *client, const struct
i2c_device_id *id)
data->resolution = 12;
data->sample_time = HZ / 4;
break;
+ case g751:
case lm75:
case lm75a:
data->resolution = 9;
@@ -296,6 +298,7 @@ static const struct i2c_device_id lm75_ids[] = {
{ "ds1775", ds1775, },
{ "ds75", ds75, },
{ "ds7505", ds7505, },
+ { "g751", g751, },
{ "lm75", lm75, },
{ "lm75a", lm75a, },
{ "max6625", max6625, },
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CRYPTO: async_tx: Fixed a couple of typos
Fixed 2 typos in async_xor.c
---
crypto/async_tx/async_xor.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index 8ade0a0..bcaa1e9 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -48,7 +48,7 @@ do_async_xor(struct dma_chan *chan, struct page *dest, struct
page **src_list,
int xor_src_cnt = 0;
dma_addr_t dma_dest;
- /* map the dest bidrectional in case it is re-used as a source */
+ /* map the dest bidirectional in case it is re-used as a source */
dma_dest = dma_map_page(dma->dev, dest, offset, len, DMA_BIDIRECTIONAL);
for (i = 0; i < src_cnt; i++) {
/* only map the dest once */
@@ -175,7 +175,7 @@ do_sync_xor(struct page *dest, struct page **src_list,
unsigned int offset,
* xor_blocks always uses the dest as a source so the
* ASYNC_TX_XOR_ZERO_DST flag must be set to not include dest data in
* the calculation. The assumption with dma eninges is that they only
- * use the destination buffer as a source when it is explicity specified
+ * use the destination buffer as a source when it is explicitly specified
* in the source list.
*
* src_list note: if the dest is also a source it must be at index zero.
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv0] hwmon: Add support for GMT G751 Temp. Sensor and Thermal Watchdog
Hi Guenter, Guenter Roeck writes: >> Sadly (for me), you are not: I compared the GMT G751 datasheet to an >> original (1996) National semiconductor LM75 datasheet and they are >> identical. I mean both the structure and full content (text, diagrams, >> etc) is the same. Lesson learned: next time I start a driver, I will ask >> if it ressembles an existing supported chip beforehand. >> > > Hi Arnaud, > > that is interesting; I thought it is Yet Another Clone, not really exactly > the same chip. If you want to compare: http://www.ieap.uni-kiel.de/surface/ag-berndt/lehre/fpmc/ns/lm75.pdf http://natisbad.org/NAS4/refs/GMT_G751.pdf >>> Please use the lm75 driver and add the g751 parameters to it. >> >> I will test if the driver does indeed work as expected to drive the G751 >> and will send a patch to document compatibility w/ GMT G751 (Kconfig, >> i2c_device_id struct and lm75_detect function). While I am at it, if you >> see something in the patch I pushed which could be useful for current >> lm75 driver (doc, sysfs, of_ part for polarity, ...), just tell me. >> > > Depends on what you need. The fault_queue and mode sysfs attributes are > neither > necessary nor acceptable - hwmon has well defined attributes, and new ones > are only added after discussion. If you _need_ to configure polarity, > interrupt mode, or fault queue depth in your application to anything but > the default, we might discuss adding those as devicetree properties. > However, you would have to make sure that it does not negatively affect > the other chips supported by the driver, and we should then discuss > if other properties should be supported as well. Overall, I strongly suspect > that the HW is happy with the default configuration. If so, we should just > leave > it alone. Let's keep lm75 in I2C trivial devices list. > Power control (the shutdown attribute) should be handled through the PM > subsystem; see CONFIG_PM / CONFIG_PM_SLEEP in other drivers. If your hardware > can sleep (which may be somewhat unlikely for a NAS), lm75 driver does have #ifdef CONFIG_PM (or am I missing something?), but you are right, I don't think the NAS can take advantage of it ATM. I just finished the a first version of a patch for lm75 to reference g751. I'll send it in a separate email. Anyway, thanks for the quick feedback. Cheers, a+ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11 00/94] 3.11.8-stable review
On Sat, Nov 09, 2013 at 09:00:28AM -0800, Guenter Roeck wrote: > On Fri, Nov 08, 2013 at 10:51:06PM -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.11.8 release. > > There are 94 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 Mon Nov 11 06:51:44 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.8-rc1.gz > > and the diffstat can be found below. > > > > Build test results look good: > total: 110 pass: 108 skipped: 2 fail: 0 > > qemu tests all pass. Wonderful, thanks for testing and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/74] 3.10.19-stable review
On Sat, Nov 09, 2013 at 09:01:15AM -0800, Guenter Roeck wrote: > On Fri, Nov 08, 2013 at 10:51:05PM -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.10.19 release. > > There are 74 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 Mon Nov 11 06:50:58 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.19-rc1.gz > > and the diffstat can be found below. > > > Build results look good: > total: 110 pass: 110 skipped: 0 fail: 0 > > qemu tests all pass. Yeah, 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: [PATCH 3.4 00/26] 3.4.69-stable review
On Sat, Nov 09, 2013 at 08:58:25AM -0800, Guenter Roeck wrote: > On 11/08/2013 10:51 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.69 release. > > There are 26 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 Mon Nov 11 06:50:22 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.69-rc1.gz > > and the diffstat can be found below. > > > > Build test results: > total: 103 pass: 89 skipped: 10 fail: 4 > > qemu tests all pass. > > This matches the results from the previous release. Great, 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 3.10 00/74] 3.10.19-stable review
On Fri, Nov 08, 2013 at 10:51:05PM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.19 release. > There are 74 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 Mon Nov 11 06:50:58 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.19-rc1.gz > and the diffstat can be found below. > Build results look good: total: 110 pass: 110 skipped: 0 fail: 0 qemu tests all pass. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11 00/94] 3.11.8-stable review
On Fri, Nov 08, 2013 at 10:51:06PM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.11.8 release. > There are 94 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 Mon Nov 11 06:51:44 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.8-rc1.gz > and the diffstat can be found below. > Build test results look good: total: 110 pass: 108 skipped: 2 fail: 0 qemu tests all pass. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/26] 3.4.69-stable review
On 11/08/2013 10:51 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.69 release. There are 26 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 Mon Nov 11 06:50:22 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.69-rc1.gz and the diffstat can be found below. Build test results: total: 103 pass: 89 skipped: 10 fail: 4 qemu tests all pass. This matches the results from the previous release. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/24] mm/lib/swiotlb: Use memblock apis for early memory allocations
Santosh Shilimkar wrote:
>Switch to memblock interfaces for early memory allocator instead of
>bootmem allocator. No functional change in beahvior than what it is
>in current code from bootmem users points of view.
>
>Archs already converted to NO_BOOTMEM now directly use memblock
>interfaces instead of bootmem wrappers build on top of memblock. And
>the
>archs which still uses bootmem, these new apis just fallback to exiting
>bootmem APIs.
>
>Cc: Yinghai Lu
>Cc: Tejun Heo
>Cc: Andrew Morton
>Cc: Konrad Rzeszutek Wilk
>
>Signed-off-by: Santosh Shilimkar
>---
> lib/swiotlb.c | 36 +---
> 1 file changed, 21 insertions(+), 15 deletions(-)
>
>diff --git a/lib/swiotlb.c b/lib/swiotlb.c
>index 4e8686c..78ac01a 100644
>--- a/lib/swiotlb.c
>+++ b/lib/swiotlb.c
>@@ -169,8 +169,9 @@ int __init swiotlb_init_with_tbl(char *tlb,
>unsigned long nslabs, int verbose)
> /*
>* Get the overflow emergency buffer
>*/
>- v_overflow_buffer = alloc_bootmem_low_pages_nopanic(
>- PAGE_ALIGN(io_tlb_overflow));
>+ v_overflow_buffer = memblock_virt_alloc_align_nopanic(
>+ PAGE_ALIGN(io_tlb_overflow),
>+ PAGE_SIZE);
Does this guarantee that the pages will be allocated below 4GB?
> if (!v_overflow_buffer)
> return -ENOMEM;
>
>@@ -181,11 +182,15 @@ int __init swiotlb_init_with_tbl(char *tlb,
>unsigned long nslabs, int verbose)
>* to find contiguous free memory regions of size up to IO_TLB_SEGSIZE
>* between io_tlb_start and io_tlb_end.
>*/
>- io_tlb_list = alloc_bootmem_pages(PAGE_ALIGN(io_tlb_nslabs *
>sizeof(int)));
>+ io_tlb_list = memblock_virt_alloc_align(
>+ PAGE_ALIGN(io_tlb_nslabs * sizeof(int)),
>+ PAGE_SIZE);
> for (i = 0; i < io_tlb_nslabs; i++)
> io_tlb_list[i] = IO_TLB_SEGSIZE - OFFSET(i, IO_TLB_SEGSIZE);
> io_tlb_index = 0;
>- io_tlb_orig_addr = alloc_bootmem_pages(PAGE_ALIGN(io_tlb_nslabs *
>sizeof(phys_addr_t)));
>+ io_tlb_orig_addr = memblock_virt_alloc_align(
>+ PAGE_ALIGN(io_tlb_nslabs * sizeof(phys_addr_t)),
>+ PAGE_SIZE);
>
> if (verbose)
> swiotlb_print_info();
>@@ -212,13 +217,14 @@ swiotlb_init(int verbose)
> bytes = io_tlb_nslabs << IO_TLB_SHIFT;
>
> /* Get IO TLB memory from the low pages */
>- vstart = alloc_bootmem_low_pages_nopanic(PAGE_ALIGN(bytes));
>+ vstart = memblock_virt_alloc_align_nopanic(PAGE_ALIGN(bytes),
>+ PAGE_SIZE);
Ditto?
> if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose))
> return;
>
> if (io_tlb_start)
>- free_bootmem(io_tlb_start,
>- PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
>+ memblock_free_early(io_tlb_start,
>+ PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
> pr_warn("Cannot allocate SWIOTLB buffer");
> no_iotlb_memory = true;
> }
>@@ -354,14 +360,14 @@ void __init swiotlb_free(void)
> free_pages((unsigned long)phys_to_virt(io_tlb_start),
> get_order(io_tlb_nslabs << IO_TLB_SHIFT));
> } else {
>- free_bootmem_late(io_tlb_overflow_buffer,
>-PAGE_ALIGN(io_tlb_overflow));
>- free_bootmem_late(__pa(io_tlb_orig_addr),
>-PAGE_ALIGN(io_tlb_nslabs *
>sizeof(phys_addr_t)));
>- free_bootmem_late(__pa(io_tlb_list),
>-PAGE_ALIGN(io_tlb_nslabs * sizeof(int)));
>- free_bootmem_late(io_tlb_start,
>-PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
>+ memblock_free_late(io_tlb_overflow_buffer,
>+ PAGE_ALIGN(io_tlb_overflow));
>+ memblock_free_late(__pa(io_tlb_orig_addr),
>+ PAGE_ALIGN(io_tlb_nslabs *
>sizeof(phys_addr_t)));
>+ memblock_free_late(__pa(io_tlb_list),
>+ PAGE_ALIGN(io_tlb_nslabs * sizeof(int)));
>+ memblock_free_late(io_tlb_start,
>+ PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
> }
> io_tlb_nslabs = 0;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv0] hwmon: Add support for GMT G751 Temp. Sensor and Thermal Watchdog
On 11/09/2013 07:56 AM, Arnaud Ebalard wrote: Hi, Guenter Roeck writes: On 11/08/2013 03:31 PM, Arnaud Ebalard wrote: This patch adds support for GMT G751 Temperature Sensor and Thermal Watchdog I2C chip. It has been tested via DT on a Netgear ReadyNAS 2120 (Marvell Armada XP based ARM device). Signed-off-by: Arnaud Ebalard Arnaud, unless I am missing something, this is just an lm75 with a different name. Sadly (for me), you are not: I compared the GMT G751 datasheet to an original (1996) National semiconductor LM75 datasheet and they are identical. I mean both the structure and full content (text, diagrams, etc) is the same. Lesson learned: next time I start a driver, I will ask if it ressembles an existing supported chip beforehand. Hi Arnaud, that is interesting; I thought it is Yet Another Clone, not really exactly the same chip. Please use the lm75 driver and add the g751 parameters to it. I will test if the driver does indeed work as expected to drive the G751 and will send a patch to document compatibility w/ GMT G751 (Kconfig, i2c_device_id struct and lm75_detect function). While I am at it, if you see something in the patch I pushed which could be useful for current lm75 driver (doc, sysfs, of_ part for polarity, ...), just tell me. Depends on what you need. The fault_queue and mode sysfs attributes are neither necessary nor acceptable - hwmon has well defined attributes, and new ones are only added after discussion. If you _need_ to configure polarity, interrupt mode, or fault queue depth in your application to anything but the default, we might discuss adding those as devicetree properties. However, you would have to make sure that it does not negatively affect the other chips supported by the driver, and we should then discuss if other properties should be supported as well. Overall, I strongly suspect that the HW is happy with the default configuration. If so, we should just leave it alone. Power control (the shutdown attribute) should be handled through the PM subsystem; see CONFIG_PM / CONFIG_PM_SLEEP in other drivers. If your hardware can sleep (which may be somewhat unlikely for a NAS), you could add support for it to the driver. That is the one improvement I could think of that might make sense. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] uprobes: uprobe_copy_process() and copy_insn() fixes
Ingo, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes/core I do not like to spam you, but I think that at least the 1st patch should be merged now, along with other retprobe && fork fixed. The 1st one-liner fixes the typo in the recently merged aa59c53fd459 "uprobes: Change uprobe_copy_process() to dup xol_area", a ret-probed child still can crash. The 2nd patch fixes the easy-to-trigger kernel crash. This bug is very old, but fortunately only root can enable uprobes. Oleg Nesterov (2): uprobes: Fix the wrong usage of current->utask in uprobe_copy_process() uprobes: Fix the memory out of bound overwrite in copy_insn() kernel/events/uprobes.c | 49 +++ 1 files changed, 24 insertions(+), 25 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 3.4 00/26] 3.4.69-stable review
On Sat, Nov 09, 2013 at 11:24:09PM +0900, Satoru Takeuchi wrote: > At Fri, 8 Nov 2013 22:51:29 -0800, > Greg Kroah-Hartman wrote: > > > > This is the start of the stable review cycle for the 3.4.69 release. > > There are 26 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 Mon Nov 11 06:50:22 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. > > - Build Machine: debian jessy x86_64 >CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 >memory: 8GB > > - Test machine: debian jessy x86_64(KVM guest on the Build Machine) >vCPU: x2 >memory: 2GB Wonderful, thanks for testing and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regmap: Fix compile warning with value uninitialized
On Sat, Nov 09, 2013 at 04:34:07PM +0100, Levente Kurusa wrote:
> 2013-11-09 16:16 keltezéssel, Mark Brown írta:
> > On Sat, Nov 09, 2013 at 09:49:11AM +, Caizhiyong wrote:
> >
> >> @@ -2170,7 +2170,8 @@ int regmap_register_patch(struct regmap *map, const
> >> struct reg_default *regs,
> >> int num_regs)
> >> {
> >>struct reg_default *p;
> >> - int i, ret;
> >> + int i;
> >> + int ret = 0;
> >>bool bypass;
> Wouldn't the following be better?
>
> int i, ret = 0;
>
> I think it is more readable.
No, please put them on separate lines like the patch did.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf/tracepoint: another fuzzer generated lockup
On Sat, Nov 09, 2013 at 04:59:38PM +0100, Peter Zijlstra wrote: > On Sat, Nov 09, 2013 at 04:27:01PM +0100, Frederic Weisbecker wrote: > > In fact, raising an irq work from an irq work should simply be prohibited. > > That's not a sane > > behaviour. > > Well, it is because as you raised on IRC we could be holding locks and > trying to avoid deadlocks. This is the very reason irq_work gets used in > printk. > > And its not a recursive run()->work()->queue() either, because as you said > this > tracepoint is in arch code _after_ work_run completes. Yeah, indeed :( > > All in all an exceedingly vexing issue. Yep, the only sane way to solve this now is to check that signal pending, unfortunately as you said it's not acquired that we can even just check this lockless... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3.10 50/74] uio: provide vm access to UIO_MEM_PHYS maps
On Sat, Nov 09, 2013 at 03:22:16PM +0100, Uwe Kleine-König wrote: > On Fri, Nov 08, 2013 at 10:51:55PM -0800, Greg Kroah-Hartman wrote: > > 3.10-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Uwe Kleine-König > > > > commit 7294151d0592e0ff48c61fca9fd7c93d613134da upstream. > > > > This makes it possible to let gdb access mappings of the process that is > > being debugged. > > > > uio_mmap_logical was moved and uio_vm_ops renamed to group related code > > and differentiate to new stuff. > I wonder why you picked that one for stable?! Because of a bugfix in a later patch that requires this one... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v5 0/9] liblockdep: userspace lockdep
On Fri, Nov 08, 2013 at 12:04:18PM -0500, Sasha Levin wrote: > > > >* Sasha Levin wrote: > > > >>On 07/08/2013 04:39 AM, Ingo Molnar wrote: > >>> > >>>* Sasha Levin wrote: > >>> > >>The other issue is that with lock classes disabled you have to hit an > >>actual deadlock to trigger any output. > >> > >>I.e. much of the power of lockdep is diminished :-/ When actual > >>deadlocks are triggered then it's not particularly complex to debug > >>user-space apps: gdb the hung task(s) and look at the backtraces. > > > >Lock classes are disabled only if you're using the LD_PRELOAD method > >of testing. If you actually re-compile your code with the library (by > >just including the header and setting a #define to enable it) you will > >have lock classes. > > Hi Ingo, > > Just wondering if you're planning on pushing it over to Linus from your > tree, or should I go ahead and do it on my own? > >>> > >>>PeterZ is in favor as well so I'll apply them after the merge window, for > >>>v3.12. > >> > >>Hi Ingo, > >> > >>Do you intend to send liblockdep in this merge window as planned? > > > >If Peter agrees with them and picks them up then the next merge window > >would be fine I guess. > > Ping? Anyone? Urgh, I missed Ingo throwing the ball back in my court.. sorry about that. I'll have a look on Monday. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf/tracepoint: another fuzzer generated lockup
On Sat, Nov 09, 2013 at 04:27:01PM +0100, Frederic Weisbecker wrote: > In fact, raising an irq work from an irq work should simply be prohibited. > That's not a sane > behaviour. Well, it is because as you raised on IRC we could be holding locks and trying to avoid deadlocks. This is the very reason irq_work gets used in printk. And its not a recursive run()->work()->queue() either, because as you said this tracepoint is in arch code _after_ work_run completes. All in all an exceedingly vexing issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv0] hwmon: Add support for GMT G751 Temp. Sensor and Thermal Watchdog
Hi, Guenter Roeck writes: > On 11/08/2013 03:31 PM, Arnaud Ebalard wrote: >> >> This patch adds support for GMT G751 Temperature Sensor and Thermal >> Watchdog I2C chip. It has been tested via DT on a Netgear ReadyNAS >> 2120 (Marvell Armada XP based ARM device). >> >> Signed-off-by: Arnaud Ebalard > > Arnaud, > > unless I am missing something, this is just an lm75 with a different > name. Sadly (for me), you are not: I compared the GMT G751 datasheet to an original (1996) National semiconductor LM75 datasheet and they are identical. I mean both the structure and full content (text, diagrams, etc) is the same. Lesson learned: next time I start a driver, I will ask if it ressembles an existing supported chip beforehand. > Please use the lm75 driver and add the g751 parameters to it. I will test if the driver does indeed work as expected to drive the G751 and will send a patch to document compatibility w/ GMT G751 (Kconfig, i2c_device_id struct and lm75_detect function). While I am at it, if you see something in the patch I pushed which could be useful for current lm75 driver (doc, sysfs, of_ part for polarity, ...), just tell me. Cheers, a+ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8
Just in case let me repeat, I can be easily wrong because I forgot how this series actually look and I don't have the patches now ;) On 11/09, Frederic Weisbecker wrote: > > On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov wrote: > > On 11/08, Frederic Weisbecker wrote: > > > > > > > > > Does this feature only work on data breakpoint or is instruction > > > breakpoint > > > address range supported as well? > > > > IIRC, execute range is supported as well. > > > > But. I can't look at the code now, but iirc this can't really work until > > we fix the (already discussed) problems with bp_len && X86_BREAKPOINT_LEN_X. > > IOW, we should not blame these patches if it doesn't work. > > Yeah, don't worry I don't plan to push back these patches for the sake of > that bug, > that would be definetly unfair, especially as I introduced that issue :) > > And the patchset looks good overall, except for a few details but it's mostly > ok, OK, > I just would like to fix that issue along the way. It would be really nice if > we can > avoid having a mask _and_ a len for breakpoints. Up to you and Suravee, but can't we cleanup this later? This series was updated many times to address a lot of (sometimes contradictory) complaints. > I mean, that doesn't look right to me, > it's two units basically measuring the same thing, so that's asking for > conflicting troubles. Yes. And we can kill either _len or _mask, not sure what would be more clean. At least with the current implementation (again, iirc) mask == len -1. Although amd supports the more generic masks (but I can't recall the details). > I'm just not sure how to reuse the len to express breakpoint ranges (that was > in fact the > initial purpose of it) without breaking the tools. Confused... user-space still uses len to express the range? Just the kernel "switches" to mask if len > 8 ? Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block: xen-blkfront: Fix possible NULL ptr dereference
In the blkif_release function the bdget_disk() call might returns a NULL ptr which might be dereferenced on bdev->bd_openers checking Signed-off-by: Felipe Pena --- drivers/block/xen-blkfront.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index a4660bb..7bb1552 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1959,6 +1959,9 @@ static void blkif_release(struct gendisk *disk, fmode_t mode) bdev = bdget_disk(disk, 0); + if (!bdev) + goto out_mutex; + if (bdev->bd_openers) goto out; @@ -1989,6 +1992,7 @@ static void blkif_release(struct gendisk *disk, fmode_t mode) out: bdput(bdev); +out_mutex: mutex_unlock(_mutex); } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regmap: Fix compile warning with value uninitialized
2013-11-09 16:16 keltezéssel, Mark Brown írta:
> On Sat, Nov 09, 2013 at 09:49:11AM +, Caizhiyong wrote:
>
>> @@ -2170,7 +2170,8 @@ int regmap_register_patch(struct regmap *map, const
>> struct reg_default *regs,
>>int num_regs)
>> {
>> struct reg_default *p;
>> -int i, ret;
>> +int i;
>> +int ret = 0;
>> bool bypass;
Wouldn't the following be better?
int i, ret = 0;
I think it is more readable.
>
> This sort of fix isn't ideal, it just silences the warning but if the
> compiler has spotted a genuine oversight in the function it won't
> address it. It's better to include some analysis of why this is a good
> fix.
>
The only condition when 'ret' is not set is when the num_regs parameter is zero
and krealloc doesn't fail. If the above two conditions apply, then
the code would return an uninitialized value. However, calling this function
with
num_regs == 0, would be a waste as it essentially does nothing.
Also, I think code which throws warnings is worse than code
which doesn't.
--
Regards,
Levente Kurusa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8
On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov wrote: > On 11/08, Frederic Weisbecker wrote: > > > > On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com > > wrote: > > > > > > diff --git a/arch/x86/include/asm/cpufeature.h > > > b/arch/x86/include/asm/cpufeature.h > > > index d3f5c63..26609bb 100644 > > > --- a/arch/x86/include/asm/cpufeature.h > > > +++ b/arch/x86/include/asm/cpufeature.h > > > @@ -170,6 +170,7 @@ > > > #define X86_FEATURE_TOPOEXT (6*32+22) /* topology extensions CPUID > > > leafs */ > > > #define X86_FEATURE_PERFCTR_CORE (6*32+23) /* core performance counter > > > extensions */ > > > #define X86_FEATURE_PERFCTR_NB (6*32+24) /* NB performance counter > > > extensions */ > > > +#define X86_FEATURE_BPEXT(6*32+26) /* data breakpoint extension > > > */ > > > > Does this feature only work on data breakpoint or is instruction breakpoint > > address range supported as well? > > IIRC, execute range is supported as well. > > But. I can't look at the code now, but iirc this can't really work until > we fix the (already discussed) problems with bp_len && X86_BREAKPOINT_LEN_X. > IOW, we should not blame these patches if it doesn't work. Yeah, don't worry I don't plan to push back these patches for the sake of that bug, that would be definetly unfair, especially as I introduced that issue :) And the patchset looks good overall, except for a few details but it's mostly ok, I just would like to fix that issue along the way. It would be really nice if we can avoid having a mask _and_ a len for breakpoints. I mean, that doesn't look right to me, it's two units basically measuring the same thing, so that's asking for conflicting troubles. I'm just not sure how to reuse the len to express breakpoint ranges (that was in fact the initial purpose of it) without breaking the tools. Any idea? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf/tracepoint: another fuzzer generated lockup
On Sat, Nov 09, 2013 at 04:22:57PM +0100, Frederic Weisbecker wrote:
> > ---
> > kernel/events/core.c | 14 --
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 4dc078d18929..a3ad40f347c4 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -5289,6 +5289,16 @@ static void perf_log_throttle(struct perf_event
> > *event, int enable)
> > perf_output_end();
> > }
> >
> > +static inline void perf_pending(struct perf_event *event)
> > +{
> > + if (in_nmi()) {
> > + irq_work_pending(>pending);
>
> I guess you mean irq_work_queue()?
Uhm yah
> But there are much more reasons that just being in nmi to async
> wakeups, signal sending, etc... The fact that an event can happen
> anywhere (rq lock acquire or whatever) makes perf events all fragile
> enough to always require irq work for these.
Fair enough :/
> Probably what we need is rather some limit. Maybe we can't seriously
> apply recursion checks here but perhaps the simple fact that we raise
> an irq work from an irq work should trigger an alarm of some sort.
I think irq_work was designed explicitly to allow this -- Oleg had some
usecase for this.
So my initial approach was trying to detect if there was a fasync signal
pending and break out of the loop in that case; but fasync gives me a
bloody headache.
It looks like you cannot even determine the signum you need to test
pending without acquiring locks, let alone find all the tasks it would
raise it against.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf/tracepoint: another fuzzer generated lockup
On Sat, Nov 09, 2013 at 04:13:56PM +0100, Peter Zijlstra wrote: > On Sat, Nov 09, 2013 at 03:52:59PM +0100, Frederic Weisbecker wrote: > > So, an idea of what may be happening: an event overflows while FASYNC flag > > is set so it triggers an irq work > > to send the signal (kill_fasync). > > After the irq work triggers, it generates an irq_work_exit event, which in > > turn overflows and, > > if it has FASYNC, triggers a new irq work. The irq work triggers and > > generates an irq work exit event which > > has FASYNC flag, etc... > > > > Looks like a nice way to deadlock with an infinite loop of irq work. > > > Yep, exactly, see the email I just send. In fact, raising an irq work from an irq work should simply be prohibited. That's not a sane behaviour. It's natural for async stuffs that have reasonable delays between each pass allow re-enqueuing, like workqueue or rcu callbacks, or timers. But with irq work that doesn't look right, expect for lazy irq works though. But lets just not allow it at all :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf/tracepoint: another fuzzer generated lockup
On Sat, Nov 09, 2013 at 04:11:01PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 08, 2013 at 11:36:58PM +0100, Frederic Weisbecker wrote:
> > [ 237.359091] [] perf_callchain_kernel+0x51/0x70
> > [ 237.365155] [] perf_callchain+0x256/0x2c0
> > [ 237.370783] [] perf_prepare_sample+0x27b/0x300
> > [ 237.376849] [] ? __rcu_is_watching+0x1a/0x30
> > [ 237.382736] [] __perf_event_overflow+0x14c/0x310
> > [ 237.388973] [] ? __perf_event_overflow+0xf9/0x310
> > [ 237.395291] [] ? trace_hardirqs_off+0xd/0x10
> > [ 237.401186] [] ? _raw_spin_unlock_irqrestore+0x53/0x90
> > [ 237.407941] [] ? do_send_sig_info+0x66/0x90
> > [ 237.413744] [] perf_swevent_overflow+0xa9/0xc0
> > [ 237.419808] [] perf_swevent_event+0x5f/0x80
> > [ 237.425610] [] perf_tp_event+0x128/0x420
> > [ 237.431154] [] ?
> > smp_trace_irq_work_interrupt+0x98/0x2a0
> > [ 237.438085] [] ? _raw_read_unlock+0x35/0x60
> > [ 237.443887] [] perf_trace_x86_irq_vector+0xc7/0xe0
> > [ 237.450295] [] ?
> > smp_trace_irq_work_interrupt+0x98/0x2a0
> > [ 237.457226] [] smp_trace_irq_work_interrupt+0x98/0x2a0
> > [ 237.463983] [] trace_irq_work_interrupt+0x72/0x80
> > [ 237.470303] [] ? retint_restore_args+0x13/0x13
> > [ 237.476366] [] ? _raw_spin_unlock_irqrestore+0x7a/0x90
> > [ 237.483117] [] rcu_process_callbacks+0x1db/0x530
> > [ 237.489360] [] __do_softirq+0xdd/0x490
> > [ 237.494728] [] irq_exit+0x96/0xc0
> > [ 237.499668] []
> > smp_trace_apic_timer_interrupt+0x5a/0x2b4
> > [ 237.506596] [] trace_apic_timer_interrupt+0x72/0x80
>
> Cute.. so what appears to happen is that:
>
> 1) we trace irq_work_exit
> 2) we generate event
> 3) event needs to deliver signal
> 4) we queue irq_work to send signal
> 5) goto 1
>
> Does something like this solve it?
>
> ---
> kernel/events/core.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 4dc078d18929..a3ad40f347c4 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5289,6 +5289,16 @@ static void perf_log_throttle(struct perf_event
> *event, int enable)
> perf_output_end();
> }
>
> +static inline void perf_pending(struct perf_event *event)
> +{
> + if (in_nmi()) {
> + irq_work_pending(>pending);
I guess you mean irq_work_queue()?
But there are much more reasons that just being in nmi to async wakeups, signal
sending, etc...
The fact that an event can happen anywhere (rq lock acquire or whatever) makes
perf events all fragile
enough to always require irq work for these.
Probably what we need is rather some limit. Maybe we can't seriously apply
recursion checks here
but perhaps the simple fact that we raise an irq work from an irq work should
trigger an alarm
of some sort.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On 11/09, Masami Hiramatsu wrote: > > In that case, I suggest you to use "@+addr" for the relative address, > since that is an offset, isn't that? :) Agreed, @+addr looks better! > BTW, it seems that @addr syntax is hard to use for uprobes, because > current uprobes is based on a binary, not a process, we cannot specify > which process is probed when we define it. Yes, exactly. That is why we suggest that user-space should pass the ip-relative address (actually offset). This should hopefully solve all problems with relocations. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Ceph: allocate non-zero page to fscache in readpage()
Li, that's a good good catch. On Fri, Nov 8, 2013 at 9:26 PM, Li Wang wrote: > ceph_osdc_readpages() returns number of bytes read, currently, > the code only allocate full-zero page into fscache, this patch > fixes this. > > Signed-off-by: Li Wang > --- > fs/ceph/addr.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c > index 6df8bd4..1e561c0 100644 > --- a/fs/ceph/addr.c > +++ b/fs/ceph/addr.c > @@ -216,7 +216,7 @@ static int readpage_nounlock(struct file *filp, struct > page *page) > } > SetPageUptodate(page); > > - if (err == 0) > + if (err >= 0) > ceph_readpage_to_fscache(inode, page); > > out: > -- > 1.7.9.5 > -- Milosz Tanski CTO 10 East 53rd Street, 37th floor New York, NY 10022 p: 646-253-9055 e: mil...@adfin.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regmap: Fix compile warning with value uninitialized
On Sat, Nov 09, 2013 at 09:49:11AM +, Caizhiyong wrote:
> @@ -2170,7 +2170,8 @@ int regmap_register_patch(struct regmap *map, const
> struct reg_default *regs,
> int num_regs)
> {
> struct reg_default *p;
> - int i, ret;
> + int i;
> + int ret = 0;
> bool bypass;
This sort of fix isn't ideal, it just silences the warning but if the
compiler has spotted a genuine oversight in the function it won't
address it. It's better to include some analysis of why this is a good
fix.
signature.asc
Description: Digital signature
Re: [PATCH v3] mm, oom: Fix race when selecting process to kill
On 11/08, Sameer Nanda wrote: > > @@ -413,12 +413,20 @@ void oom_kill_process(struct task_struct *p, gfp_t > gfp_mask, int order, > DEFAULT_RATELIMIT_BURST); > @@ -456,10 +463,18 @@ void oom_kill_process(struct task_struct *p, gfp_t > gfp_mask, int order, > } > } > } while_each_thread(p, t); > - read_unlock(_lock); > > rcu_read_lock(); > + > p = find_lock_task_mm(victim); > + > + /* > + * Since while_each_thread is currently not RCU safe, this unlock of > + * tasklist_lock may need to be moved further down if any additional > + * while_each_thread loops get added to this function. > + */ > + read_unlock(_lock); Well, ack... but with this change find_lock_task_mm() relies on tasklist, so it makes sense to move rcu_read_lock() down before for_each_process(). Otherwise this looks confusing, but I won't insist. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf/tracepoint: another fuzzer generated lockup
On Sat, Nov 09, 2013 at 03:52:59PM +0100, Frederic Weisbecker wrote: > So, an idea of what may be happening: an event overflows while FASYNC flag is > set so it triggers an irq work > to send the signal (kill_fasync). > After the irq work triggers, it generates an irq_work_exit event, which in > turn overflows and, > if it has FASYNC, triggers a new irq work. The irq work triggers and > generates an irq work exit event which > has FASYNC flag, etc... > > Looks like a nice way to deadlock with an infinite loop of irq work. Yep, exactly, see the email I just send. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf/tracepoint: another fuzzer generated lockup
On Fri, Nov 08, 2013 at 11:36:58PM +0100, Frederic Weisbecker wrote:
> [ 237.359091] [] perf_callchain_kernel+0x51/0x70
> [ 237.365155] [] perf_callchain+0x256/0x2c0
> [ 237.370783] [] perf_prepare_sample+0x27b/0x300
> [ 237.376849] [] ? __rcu_is_watching+0x1a/0x30
> [ 237.382736] [] __perf_event_overflow+0x14c/0x310
> [ 237.388973] [] ? __perf_event_overflow+0xf9/0x310
> [ 237.395291] [] ? trace_hardirqs_off+0xd/0x10
> [ 237.401186] [] ? _raw_spin_unlock_irqrestore+0x53/0x90
> [ 237.407941] [] ? do_send_sig_info+0x66/0x90
> [ 237.413744] [] perf_swevent_overflow+0xa9/0xc0
> [ 237.419808] [] perf_swevent_event+0x5f/0x80
> [ 237.425610] [] perf_tp_event+0x128/0x420
> [ 237.431154] [] ? smp_trace_irq_work_interrupt+0x98/0x2a0
> [ 237.438085] [] ? _raw_read_unlock+0x35/0x60
> [ 237.443887] [] perf_trace_x86_irq_vector+0xc7/0xe0
> [ 237.450295] [] ? smp_trace_irq_work_interrupt+0x98/0x2a0
> [ 237.457226] [] smp_trace_irq_work_interrupt+0x98/0x2a0
> [ 237.463983] [] trace_irq_work_interrupt+0x72/0x80
> [ 237.470303] [] ? retint_restore_args+0x13/0x13
> [ 237.476366] [] ? _raw_spin_unlock_irqrestore+0x7a/0x90
> [ 237.483117] [] rcu_process_callbacks+0x1db/0x530
> [ 237.489360] [] __do_softirq+0xdd/0x490
> [ 237.494728] [] irq_exit+0x96/0xc0
> [ 237.499668] [] smp_trace_apic_timer_interrupt+0x5a/0x2b4
> [ 237.506596] [] trace_apic_timer_interrupt+0x72/0x80
Cute.. so what appears to happen is that:
1) we trace irq_work_exit
2) we generate event
3) event needs to deliver signal
4) we queue irq_work to send signal
5) goto 1
Does something like this solve it?
---
kernel/events/core.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4dc078d18929..a3ad40f347c4 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5289,6 +5289,16 @@ static void perf_log_throttle(struct perf_event *event,
int enable)
perf_output_end();
}
+static inline void perf_pending(struct perf_event *event)
+{
+ if (in_nmi()) {
+ irq_work_pending(>pending);
+ return;
+ }
+
+ perf_pending_event(>pending);
+}
+
/*
* Generic event overflow handling, sampling.
*/
@@ -5345,7 +5355,7 @@ static int __perf_event_overflow(struct perf_event *event,
ret = 1;
event->pending_kill = POLL_HUP;
event->pending_disable = 1;
- irq_work_queue(>pending);
+ perf_pending(event);
}
if (event->overflow_handler)
@@ -5355,7 +5365,7 @@ static int __perf_event_overflow(struct perf_event *event,
if (event->fasync && event->pending_kill) {
event->pending_wakeup = 1;
- irq_work_queue(>pending);
+ perf_pending(event);
}
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8
On 11/08, Frederic Weisbecker wrote: > > On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote: > > > > diff --git a/arch/x86/include/asm/cpufeature.h > > b/arch/x86/include/asm/cpufeature.h > > index d3f5c63..26609bb 100644 > > --- a/arch/x86/include/asm/cpufeature.h > > +++ b/arch/x86/include/asm/cpufeature.h > > @@ -170,6 +170,7 @@ > > #define X86_FEATURE_TOPOEXT(6*32+22) /* topology extensions CPUID > > leafs */ > > #define X86_FEATURE_PERFCTR_CORE (6*32+23) /* core performance counter > > extensions */ > > #define X86_FEATURE_PERFCTR_NB (6*32+24) /* NB performance counter > > extensions */ > > +#define X86_FEATURE_BPEXT (6*32+26) /* data breakpoint extension */ > > Does this feature only work on data breakpoint or is instruction breakpoint > address range supported as well? IIRC, execute range is supported as well. But. I can't look at the code now, but iirc this can't really work until we fix the (already discussed) problems with bp_len && X86_BREAKPOINT_LEN_X. IOW, we should not blame these patches if it doesn't work. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: gpio-regulator: Don't oops on missing regulator-type property
On Sat, Nov 09, 2013 at 01:12:28PM +0100, Laurent Pinchart wrote: > Catch missing regulator-type property in DT and return an error > gracefully instead of deferencing a NULL pointer and crashing. Applied, thanks. signature.asc Description: Digital signature
Re: perf/tracepoint: another fuzzer generated lockup
On Sat, Nov 09, 2013 at 03:10:39PM +0100, Peter Zijlstra wrote: > On Fri, Nov 08, 2013 at 11:36:58PM +0100, Frederic Weisbecker wrote: > > [ 237.627769] perf samples too long (3397569 > 2500), lowering > > kernel.perf_event_max_sample_rate to 5 > > [ 237.637124] INFO: NMI handler (perf_event_nmi_handler) took too long to > > run: 444.233 msecs > > > > 444 msecs is huge. > > Be glad your system lived to tell about it ;-) Calling printk() from NMI > context is Russian roulette; I'm still waiting for the first report it > actually locked up :-) > > That said, I'm not sure what kernel you're running, but there were some > issues with time-keeping hereabouts, but more importantly that second > timing includes the printk() call of the first -- so that's always going > to be fucked. So, an idea of what may be happening: an event overflows while FASYNC flag is set so it triggers an irq work to send the signal (kill_fasync). After the irq work triggers, it generates an irq_work_exit event, which in turn overflows and, if it has FASYNC, triggers a new irq work. The irq work triggers and generates an irq work exit event which has FASYNC flag, etc... Looks like a nice way to deadlock with an infinite loop of irq 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/
[PATCH] mm: numa: Return the number of base pages altered by protection changes
Commit 0255d491 (mm: Account for a THP NUMA hinting update as one PTE
update) was added to account for the number of PTE updates when marking
pages prot_numa. task_numa_work was using the old return value to track
how much address space had been updated. Altering the return value causes
the scanner to do more work than it is configured or documented to in a
single unit of work.
This patch reverts 0255d491 and accounts for the number of THP updates
separately in vmstat. It is up to the administrator to interpret the pair
of values correctly. This is a straight-forward operation and likely to
only be of interest when actively debugging NUMA balancing problems.
The impact of this patch is that the NUMA PTE scanner will scan slower when
THP is enabled and workloads may converge slower as a result. On the flip
size system CPU usage should be lower than recent tests reported. This is
an illustrative example of a short single JVM specjbb test
specjbb
3.12.03.12.0
vanilla acctupdates
TPut 1 26143.00 ( 0.00%) 25747.00 ( -1.51%)
TPut 7 185257.00 ( 0.00%)183202.00 ( -1.11%)
TPut 13329760.00 ( 0.00%)346577.00 ( 5.10%)
TPut 19442502.00 ( 0.00%)460146.00 ( 3.99%)
TPut 25540634.00 ( 0.00%)549053.00 ( 1.56%)
TPut 31512098.00 ( 0.00%)519611.00 ( 1.47%)
TPut 37461276.00 ( 0.00%)474973.00 ( 2.97%)
TPut 43403089.00 ( 0.00%)414172.00 ( 2.75%)
3.12.0 3.12.0
vanillaacctupdates
User 5169.64 5184.14
System100.45 80.02
Elapsed 252.75 251.85
Performance is similar but note the reduction in system CPU time. While
this showed a performance gain, it will not be universal but at least
it'll be behaving as documented. The vmstats are obviously different but
here is an obvious interpretation of them from mmtests.
3.12.0 3.12.0
vanillaacctupdates
NUMA page range updates140832611043064
NUMA huge PMD updates0 21040
NUMA PTE updates 1408326 291624
"NUMA page range updates" == nr_pte_updates and is the value returned to
the NUMA pte scanner. NUMA huge PMD updates were the number of THP updates
which in combination can be used to calculate how many ptes were updated
from userspace.
Reported-by: Alex Thorlton
Cc: sta...@vger.kernel.org
Signed-off-by: Mel Gorman
---
include/linux/vm_event_item.h | 1 +
mm/mprotect.c | 6 +-
mm/vmstat.c | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 1855f0a..c557c6d 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -39,6 +39,7 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
PAGEOUTRUN, ALLOCSTALL, PGROTATED,
#ifdef CONFIG_NUMA_BALANCING
NUMA_PTE_UPDATES,
+ NUMA_HUGE_PTE_UPDATES,
NUMA_HINT_FAULTS,
NUMA_HINT_FAULTS_LOCAL,
NUMA_PAGE_MIGRATE,
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 412ba2b..f94d2bd 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -138,6 +138,7 @@ static inline unsigned long change_pmd_range(struct
vm_area_struct *vma,
pmd_t *pmd;
unsigned long next;
unsigned long pages = 0;
+ unsigned long nr_huge_updates = 0;
bool all_same_node;
pmd = pmd_offset(pud, addr);
@@ -148,7 +149,8 @@ static inline unsigned long change_pmd_range(struct
vm_area_struct *vma,
split_huge_page_pmd(vma, addr, pmd);
else if (change_huge_pmd(vma, pmd, addr, newprot,
prot_numa)) {
- pages++;
+ pages += HPAGE_PMD_NR;
+ nr_huge_updates++;
continue;
}
/* fall through */
@@ -168,6 +170,8 @@ static inline unsigned long change_pmd_range(struct
vm_area_struct *vma,
change_pmd_protnuma(vma->vm_mm, addr, pmd);
} while (pmd++, addr = next, addr != end);
+ if (nr_huge_updates)
+ count_vm_numa_events(NUMA_HUGE_PTE_UPDATES, nr_huge_updates);
return pages;
}
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 9bb3145..5a442a7 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -812,6 +812,7 @@ const char * const vmstat_text[] = {
#ifdef CONFIG_NUMA_BALANCING
"numa_pte_updates",
+ "numa_huge_pte_updates",
"numa_hint_faults",
"numa_hint_faults_local",
"numa_pages_migrated",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 3.4 00/26] 3.4.69-stable review
At Fri, 8 Nov 2013 22:51:29 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.69 release. > There are 26 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 Mon Nov 11 06:50:22 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. - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3.10 50/74] uio: provide vm access to UIO_MEM_PHYS maps
On Fri, Nov 08, 2013 at 10:51:55PM -0800, Greg Kroah-Hartman wrote:
> 3.10-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Uwe Kleine-König
>
> commit 7294151d0592e0ff48c61fca9fd7c93d613134da upstream.
>
> This makes it possible to let gdb access mappings of the process that is
> being debugged.
>
> uio_mmap_logical was moved and uio_vm_ops renamed to group related code
> and differentiate to new stuff.
I wonder why you picked that one for stable?!
Best regards
Uwe
>
> Signed-off-by: Uwe Kleine-König
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> drivers/uio/uio.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -630,12 +630,26 @@ static int uio_vma_fault(struct vm_area_
> return 0;
> }
>
> -static const struct vm_operations_struct uio_vm_ops = {
> +static const struct vm_operations_struct uio_logical_vm_ops = {
> .open = uio_vma_open,
> .close = uio_vma_close,
> .fault = uio_vma_fault,
> };
>
> +static int uio_mmap_logical(struct vm_area_struct *vma)
> +{
> + vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
> + vma->vm_ops = _logical_vm_ops;
> + uio_vma_open(vma);
> + return 0;
> +}
> +
> +static const struct vm_operations_struct uio_physical_vm_ops = {
> +#ifdef CONFIG_HAVE_IOREMAP_PROT
> + .access = generic_access_phys,
> +#endif
> +};
> +
> static int uio_mmap_physical(struct vm_area_struct *vma)
> {
> struct uio_device *idev = vma->vm_private_data;
> @@ -643,6 +657,8 @@ static int uio_mmap_physical(struct vm_a
> if (mi < 0)
> return -EINVAL;
>
> + vma->vm_ops = _physical_vm_ops;
> +
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>
> return remap_pfn_range(vma,
> @@ -652,14 +668,6 @@ static int uio_mmap_physical(struct vm_a
> vma->vm_page_prot);
> }
>
> -static int uio_mmap_logical(struct vm_area_struct *vma)
> -{
> - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
> - vma->vm_ops = _vm_ops;
> - uio_vma_open(vma);
> - return 0;
> -}
> -
> static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
> {
> struct uio_listener *listener = filep->private_data;
>
>
>
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf/tracepoint: another fuzzer generated lockup
On Sat, Nov 09, 2013 at 03:10:39PM +0100, Peter Zijlstra wrote: > On Fri, Nov 08, 2013 at 11:36:58PM +0100, Frederic Weisbecker wrote: > > [ 237.627769] perf samples too long (3397569 > 2500), lowering > > kernel.perf_event_max_sample_rate to 5 > > [ 237.637124] INFO: NMI handler (perf_event_nmi_handler) took too long to > > run: 444.233 msecs > > > > 444 msecs is huge. > > Be glad your system lived to tell about it ;-) Calling printk() from NMI > context is Russian roulette; I'm still waiting for the first report it > actually locked up :-) Haha, right. I dump with earlyprintk but that doesn't change the fact it passes through printk machinery. Fortunately I haven't yet got burdened with that. Although... maybe printk plays a role in the issue here... > > That said, I'm not sure what kernel you're running, but there were some > issues with time-keeping hereabouts, but more importantly that second > timing includes the printk() call of the first -- so that's always going > to be fucked. It's a recent tip:master. So the delta debug printout is certainly buggy, meanwhile these lockup only happen with Vince selftests, and they trigger a lot of these NMI-too-long issues, or may be that's the other way round :)... I'm trying to narrow down the issue, lets hope the lockup is not actually due to printk itself. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf/tracepoint: another fuzzer generated lockup
On Fri, Nov 08, 2013 at 11:36:58PM +0100, Frederic Weisbecker wrote: > [ 237.627769] perf samples too long (3397569 > 2500), lowering > kernel.perf_event_max_sample_rate to 5 > [ 237.637124] INFO: NMI handler (perf_event_nmi_handler) took too long to > run: 444.233 msecs > > 444 msecs is huge. Be glad your system lived to tell about it ;-) Calling printk() from NMI context is Russian roulette; I'm still waiting for the first report it actually locked up :-) That said, I'm not sure what kernel you're running, but there were some issues with time-keeping hereabouts, but more importantly that second timing includes the printk() call of the first -- so that's always going to be fucked. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Staging: android: Add possibility to compile android drivers as modules
2013-11-09 14:15 keltezéssel, Baptiste Covolato írta: > Thanks for the review. > > Should I repost this patch with correct git commit message here or in > another mail ? Post it a new mail with a subject like [PATCH v2] or something among the lines. Also, have you tested that they compile as modules and can be insmod'ed? -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Staging: android: Add possibility to compile android drivers as modules
Thanks for the review. Should I repost this patch with correct git commit message here or in another mail ? Regards, -- Baptiste Covolato 2013/11/9 Levente Kurusa : > 2013-11-09 14:23 keltezéssel, Baptiste Covolato írta: >> Compilation of Android staging drivers as drivers is now possible. > > 'drivers as drivers'? :-) > > Also, this commit message says nothing about what the patch does. > Something like this would be more appropriate: > Edit Android Kconfig files to allow building the drivers as modules. > > > > -- > Regards, > Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Staging: android: Add possibility to compile android drivers as modules
2013-11-09 14:23 keltezéssel, Baptiste Covolato írta: > Compilation of Android staging drivers as drivers is now possible. 'drivers as drivers'? :-) Also, this commit message says nothing about what the patch does. Something like this would be more appropriate: Edit Android Kconfig files to allow building the drivers as modules. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: gpio-regulator: Don't oops on missing regulator-type property
Catch missing regulator-type property in DT and return an error
gracefully instead of deferencing a NULL pointer and crashing.
Signed-off-by: Laurent Pinchart
---
drivers/regulator/gpio-regulator.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/gpio-regulator.c
b/drivers/regulator/gpio-regulator.c
index 98a98ff..bcd827c 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -139,6 +139,7 @@ of_get_gpio_regulator_config(struct device *dev, struct
device_node *np)
struct property *prop;
const char *regtype;
int proplen, gpio, i;
+ int ret;
config = devm_kzalloc(dev,
sizeof(struct gpio_regulator_config),
@@ -202,7 +203,11 @@ of_get_gpio_regulator_config(struct device *dev, struct
device_node *np)
}
config->nr_states = i;
- of_property_read_string(np, "regulator-type", );
+ ret = of_property_read_string(np, "regulator-type", );
+ if (ret < 0) {
+ dev_err(dev, "Missing 'regulator-type' property\n");
+ return ERR_PTR(-EINVAL);
+ }
if (!strncmp("voltage", regtype, 7))
config->type = REGULATOR_VOLTAGE;
--
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/
Re: [PATCH] mfd: wm831x: Use PM ops for shutdown
On Fri, Nov 08, 2013 at 06:51:26PM +, Mark Brown wrote: > From: Mark Brown > > This helps move us towards removing the bus custom operations. > > Signed-off-by: Mark Brown Acked-by: Charles Keepax Thanks, Charles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block: cmdline-parser: perfect cmdline format checking
From: Cai Zhiyong
Date: Sat, 9 Nov 2013 19:27:38 +0800
Subject: [PATCH] block: cmdline-parser: perfect cmdline format checking
-Fix compile warning with value and function undeclared.
this reported by and
Randy Dunlap
-perfect cmdline format checking, make the error information clear
for understand, make this lib fully equivalent to the old parser
in drivers/mtd/cmdlinepart.c
Signed-off-by: Cai Zhiyong
---
block/cmdline-parser.c | 86 +++---
include/linux/cmdline-parser.h | 1 +
2 files changed, 65 insertions(+), 22 deletions(-)
diff --git a/block/cmdline-parser.c b/block/cmdline-parser.c
index 9dbc67e..39b6cf4 100644
--- a/block/cmdline-parser.c
+++ b/block/cmdline-parser.c
@@ -6,10 +6,15 @@
*/
#include
#include
+#include
+
+#define PARSER "cmdline-parser: "
static int parse_subpart(struct cmdline_subpart **subpart, char *partdef)
{
int ret = 0;
+ int lastpart = 0;
+ char *partorg = partdef;
struct cmdline_subpart *new_subpart;
*subpart = NULL;
@@ -21,10 +26,12 @@ static int parse_subpart(struct cmdline_subpart **subpart,
char *partdef)
if (*partdef == '-') {
new_subpart->size = (sector_t)(~0ULL);
partdef++;
+ lastpart = 1;
} else {
new_subpart->size = (sector_t)memparse(partdef, );
if (new_subpart->size < (sector_t)PAGE_SIZE) {
- pr_warn("cmdline partition size is invalid.");
+ pr_warn(PARSER "partition '%s' size '0x%llx' too
small.",
+ partorg, new_subpart->size);
ret = -EINVAL;
goto fail;
}
@@ -42,13 +49,19 @@ static int parse_subpart(struct cmdline_subpart **subpart,
char *partdef)
char *next = strchr(++partdef, ')');
if (!next) {
- pr_warn("cmdline partition format is invalid.");
+ pr_warn(PARSER "partition '%s' has no closing ')' "
+ "found in partition name.", partorg);
ret = -EINVAL;
goto fail;
}
- length = min_t(int, next - partdef,
- sizeof(new_subpart->name) - 1);
+ length = (int)(next - partdef);
+ if (length > sizeof(new_subpart->name) - 1) {
+ pr_warn(PARSER "partition '%s' partition name too long,"
+ " truncating.", partorg);
+ length = sizeof(new_subpart->name) - 1;
+ }
+
strncpy(new_subpart->name, partdef, length);
new_subpart->name[length] = '\0';
@@ -68,8 +81,15 @@ static int parse_subpart(struct cmdline_subpart **subpart,
char *partdef)
partdef += 2;
}
+ if (*partdef) {
+ pr_warn(PARSER "partition '%s' has bad character '%c' after"
+ " partition.", partorg, *partdef);
+ ret = -EINVAL;
+ goto fail;
+ }
+
*subpart = new_subpart;
- return 0;
+ return lastpart;
fail:
kfree(new_subpart);
return ret;
@@ -86,14 +106,13 @@ static void free_subpart(struct cmdline_parts *parts)
}
}
-static int parse_parts(struct cmdline_parts **parts, const char *bdevdef)
+static int parse_parts(struct cmdline_parts **parts, char *bdevdef)
{
int ret = -EINVAL;
char *next;
int length;
struct cmdline_subpart **next_subpart;
struct cmdline_parts *newparts;
- char buf[BDEVNAME_SIZE + 32 + 4];
*parts = NULL;
@@ -102,14 +121,21 @@ static int parse_parts(struct cmdline_parts **parts,
const char *bdevdef)
return -ENOMEM;
next = strchr(bdevdef, ':');
- if (!next) {
- pr_warn("cmdline partition has no block device.");
+ if (!next || next == bdevdef) {
+ pr_warn(PARSER "partition '%s' has no block device.", bdevdef);
goto fail;
}
- length = min_t(int, next - bdevdef, sizeof(newparts->name) - 1);
+ length = (int)(next - bdevdef);
+ if (length > sizeof(newparts->name) - 1) {
+ pr_warn(PARSER "partition '%s' device name too long, "
+ "truncating.", bdevdef);
+ length = sizeof(newparts->name) - 1;
+ }
+
strncpy(newparts->name, bdevdef, length);
newparts->name[length] = '\0';
+
newparts->nr_subparts = 0;
next_subpart = >subpart;
@@ -117,23 +143,26 @@ static int parse_parts(struct cmdline_parts **parts,
const char *bdevdef)
while (next && *(++next)) {
bdevdef = next;
next = strchr(bdevdef, ',');
+ if (next)
+ *next = '\0';
-
[PATCH 2/2] mtd: cmdlinepart: support master name is not set when parser partition
From: Cai Zhiyong
Date: Sat, 9 Nov 2013 17:54:12 +0800
Subject: [PATCH 2/2] mtd: cmdlinepart: support master name is not set when
parser partition
-Fix compile warning with value and function undeclared.
this reported by and
Randy Dunlap
-support master name is not set when parser partition.
this feature is supported in the old parser.
Signed-off-by: Cai Zhiyong
---
drivers/mtd/Kconfig | 1 +
drivers/mtd/cmdlinepart.c | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index daf544a..f8f45e0 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -76,6 +76,7 @@ endif # MTD_REDBOOT_PARTS
config MTD_CMDLINE_PARTS
tristate "Command line partition table parsing"
select BLK_CMDLINE_PARSER
+ depends on BLOCK
depends on MTD
---help---
Allow generic configuration of the MTD partition tables via the kernel
diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
index ba934a4..2074164 100644
--- a/drivers/mtd/cmdlinepart.c
+++ b/drivers/mtd/cmdlinepart.c
@@ -54,6 +54,7 @@
*/
#include
+#include
#include
#include
#include
@@ -108,7 +109,12 @@ static int parse_cmdline_partitions(struct mtd_info
*master,
if (!mtd_cmdline_parts)
return 0;
- parts = cmdline_parts_find(mtd_cmdline_parts, master->name);
+ /* If master->name is not set, return the first device partition. */
+ if (!master->name)
+ parts = mtd_cmdline_parts->next_parts;
+ else
+ parts = cmdline_parts_find(mtd_cmdline_parts, master->name);
+
if (!parts)
return 0;
@@ -143,5 +149,5 @@ MODULE_PARM_DESC(mtdparts, "Partitioning specification");
module_param(mtdparts, charp, 0);
MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Marius Groeger ");
+MODULE_AUTHOR("Cai Zhiyong ");
MODULE_DESCRIPTION("Command line configuration of MTD partitions");
--
1.8.1.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] Staging: android: Add possibility to compile android drivers as modules
Compilation of Android staging drivers as drivers is now possible. Signed-off-by: Baptiste Covolato --- drivers/staging/android/Kconfig | 18 +- drivers/staging/android/TODO| 1 - 2 files changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig index 1e9ab6d..a22737d 100644 --- a/drivers/staging/android/Kconfig +++ b/drivers/staging/android/Kconfig @@ -1,7 +1,7 @@ menu "Android" config ANDROID - bool "Android Drivers" + tristate "Android Drivers" default N ---help--- Enable support for various drivers needed on the Android platform @@ -9,7 +9,7 @@ config ANDROID if ANDROID config ANDROID_BINDER_IPC - bool "Android Binder IPC Driver" + tristate "Android Binder IPC Driver" depends on MMU default n ---help--- @@ -21,7 +21,7 @@ config ANDROID_BINDER_IPC between said processes. config ASHMEM - bool "Enable the Anonymous Shared Memory Subsystem" + tristate "Enable the Anonymous Shared Memory Subsystem" default n depends on SHMEM ---help--- @@ -50,7 +50,7 @@ config ANDROID_LOGGER much overhead in the system. config ANDROID_TIMED_OUTPUT - bool "Timed output class driver" + tristate "Timed output class driver" default y config ANDROID_TIMED_GPIO @@ -59,13 +59,13 @@ config ANDROID_TIMED_GPIO default n config ANDROID_LOW_MEMORY_KILLER - bool "Android Low Memory Killer" + tristate "Android Low Memory Killer" default N ---help--- Registers processes to be killed when memory is low config ANDROID_INTF_ALARM_DEV - bool "Android alarm driver" + tristate "Android alarm driver" depends on RTC_CLASS default n ---help--- @@ -74,7 +74,7 @@ config ANDROID_INTF_ALARM_DEV Also exports the alarm interface to user-space. config SYNC - bool "Synchronization framework" + tristate "Synchronization framework" default n select ANON_INODES ---help--- @@ -83,7 +83,7 @@ config SYNC synchronization built into devices like GPUs. config SW_SYNC - bool "Software synchronization objects" + tristate "Software synchronization objects" default n depends on SYNC ---help--- @@ -92,7 +92,7 @@ config SW_SYNC the synchronization. config SW_SYNC_USER - bool "Userspace API for SW_SYNC" + tristate "Userspace API for SW_SYNC" default n depends on SW_SYNC ---help--- diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO index b15fb0d..9b7394a 100644 --- a/drivers/staging/android/TODO +++ b/drivers/staging/android/TODO @@ -2,7 +2,6 @@ TODO: - checkpatch.pl cleanups - sparse fixes - rename files to be not so "generic" - - make sure things build as modules properly - add proper arch dependencies as needed - audit userspace interfaces to make sure they are sane -- 1.8.4.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] mmc: host: sdhci: prevent mmcqd from becoming locked on mmc timeout
fixed a condition where device issues a status cmd to sdcard but no response
comes from sdcard. The sdhci irq fires and we hit a timeout case which calls
sdhci_finish_data(). sdhci_finish_data eventually attempt to reset controller
and issues stop cmd. However mmcdq is wait_for_completion(>completion)
in function mmc_wait_for_req_done which never occurs.
Signed-off-by: Neal Buckendahl
---
drivers/mmc/host/sdhci.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 6785fb1..480730f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -973,6 +973,8 @@ static void sdhci_finish_data(struct sdhci_host *host)
if (data->error) {
sdhci_reset(host, SDHCI_RESET_CMD);
sdhci_reset(host, SDHCI_RESET_DATA);
+ host->mrq->cmd->error = -ETIMEDOUT;
+ tasklet_schedule(>finish_tasklet);
}
sdhci_send_command(host, data->stop);
--
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] regmap: Fix compile warning with value uninitialized
From: Cai Zhiyong
Date: Sat, 9 Nov 2013 14:14:36 +0800
Subject: [PATCH] regmap: Fix compile warning with value uninitialized
Fix compile warning with value uninitialized:
drivers/base/regmap/regmap.c:2173: warning: 'ret' may be used uninitialized in
this function
Signed-off-by: Cai Zhiyong
---
drivers/base/regmap/regmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 9c021d9..4fac073 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2170,7 +2170,8 @@ int regmap_register_patch(struct regmap *map, const
struct reg_default *regs,
int num_regs)
{
struct reg_default *p;
- int i, ret;
+ int i;
+ int ret = 0;
bool bypass;
map->lock(map->lock_arg);
--
1.8.1.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: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
(2013/11/09 1:56), Will Deacon wrote: > Hi Sandeepa, > > On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote: >> Add support for basic kernel probes(kprobes), jump probes (jprobes) >> for ARM64. > > I think this series will conflict quite heavily with the jump_label series, > since they both introduce some common instruction manipulation code. On the > debug side, there will also be conflicts with the kgdb series, so it might > make sense for us to merge those two first, then you can rebase on a stable > branch from us. [...] > In fact, how do you avoid a race with hardware breakpoints? E.g., somebody > places a hardware breakpoint on an instruction in the kernel for which > kprobes has patched in a brk. We take the hardware breakpoint, disable the > breakpoint and set up a single step before returning to the brk. The brk > then traps, but we must take care not to disable single-step and/or unmask > debug exceptions, because that will cause the hardware breakpoint code to > re-arm its breakpoint before we've stepped off the brk instruction. Hmm, frankly to say, this kind of race issue is not seriously discussed on x86 too, since kgdb is still a special tool (not used on the production system). I think under such situation kgdb operator must have full control of the system, and he can (and has to) avoid such kind of race. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REVIEW][PATCH 1/4] vfs: Don't allow overwriting mounts in the current mount namespace
On Fri, Nov 08, 2013 at 02:17:31PM -0800, Eric W. Biederman wrote: > > Read what you've written a few lines above. The part about target->i_mutex > > being held. > > That works for the rename as unlink case but we don't hold > old_dentry->d_inode->i_mutex which is what is needed to prevent a mount > on the dentry we are renaming. It will be held in 3.13. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
