Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

On Thu, Jan 12, 2017 at 05:32:09PM +0100, Nicolas Dichtel wrote: > What I was trying to say is that I export those directories like other are. > Removing those files is not related to that series. Perhaps the correct solution is to only copy files matching "*.h" to reduce the risk of copying

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

On Thu, Jan 12, 2017 at 05:32:09PM +0100, Nicolas Dichtel wrote: > What I was trying to say is that I export those directories like other are. > Removing those files is not related to that series. Perhaps the correct solution is to only copy files matching "*.h" to reduce the risk of copying

Some dieharder results on Linux 4.1 (no red flags)

System: 4.1.0-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian 4.1.6-1~bpo8+1 (2015-09-09) x86_64 GNU/Linux Dieharder: 3.31.1-4 (debian wheezy amd64) Commandline: dieharder -d 8 -g NN -Y 2 -k 2 < /dev/urandom (test is 'diehard_count_1s_str') AES_OFB (-g 205): ran to psamples=10, final

Some dieharder results on Linux 4.1 (no red flags)

System: 4.1.0-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian 4.1.6-1~bpo8+1 (2015-09-09) x86_64 GNU/Linux Dieharder: 3.31.1-4 (debian wheezy amd64) Commandline: dieharder -d 8 -g NN -Y 2 -k 2 < /dev/urandom (test is 'diehard_count_1s_str') AES_OFB (-g 205): ran to psamples=10, final

Re: [PATCH 1/3] Make /dev/urandom scalable

On Thu, Sep 24, 2015 at 03:11:23PM -0400, Austin S Hemmelgarn wrote: > I will make a point however to run some tests over the weekend on a > current kernel version (4.2.1), with the current dieharder version I > have available (3.31.1). Please report your findings. If urandom is worse than

Re: [PATCH 1/3] Make /dev/urandom scalable

On Thu, Sep 24, 2015 at 12:00:44PM -0400, Austin S Hemmelgarn wrote: > I've had cases where I've done thousands of dieharder runs, and it > failed almost 10% of the time, while stuff like mt19937 fails in > otherwise identical tests only about 1-2% of the time That is a startling result. Please

Re: [PATCH 1/3] Make /dev/urandom scalable

On Thu, Sep 24, 2015 at 03:11:23PM -0400, Austin S Hemmelgarn wrote: > I will make a point however to run some tests over the weekend on a > current kernel version (4.2.1), with the current dieharder version I > have available (3.31.1). Please report your findings. If urandom is worse than

Re: [PATCH 1/3] Make /dev/urandom scalable

On Thu, Sep 24, 2015 at 12:00:44PM -0400, Austin S Hemmelgarn wrote: > I've had cases where I've done thousands of dieharder runs, and it > failed almost 10% of the time, while stuff like mt19937 fails in > otherwise identical tests only about 1-2% of the time That is a startling result. Please

Re: [RFC][PATCH 0/5] Fixes for abs() usage on 64bit values

On Mon, Sep 14, 2015 at 11:46:32PM -0400, Tejun Heo wrote: > Hello, > > On Mon, Sep 14, 2015 at 08:27:08PM -0700, John Stultz wrote: > > Yea. The above make sense to me, but I suspect there's some very > > subtle reason for the existing separated logic. > > But I'd have to defer to akpm for hints

Re: [RFC][PATCH 0/5] Fixes for abs() usage on 64bit values

On Mon, Sep 14, 2015 at 11:46:32PM -0400, Tejun Heo wrote: > Hello, > > On Mon, Sep 14, 2015 at 08:27:08PM -0700, John Stultz wrote: > > Yea. The above make sense to me, but I suspect there's some very > > subtle reason for the existing separated logic. > > But I'd have to defer to akpm for hints

Re: kfree a pointer "from the middle" causing protection faults

On Wed, Sep 02, 2015 at 08:32:15PM +0530, Muni Sekhar wrote: > [ Please keep me in CC as I'm not subscribed to the list] > > Hello, > > > I am getting protection faults in different kernel modules if I try to > free a pointer "from the middle" for example, look at the following > code: [..]

Re: kfree a pointer "from the middle" causing protection faults

On Wed, Sep 02, 2015 at 08:32:15PM +0530, Muni Sekhar wrote: > [ Please keep me in CC as I'm not subscribed to the list] > > Hello, > > > I am getting protection faults in different kernel modules if I try to > free a pointer "from the middle" for example, look at the following > code: [..]

Re: [x86] copy_from{to}_user question

On Mon, Aug 24, 2015 at 03:52:11PM +0800, yalin wang wrote: > i am not clear about what is STAC / SMAP ? > could you give me a link for understanding ? the first item I found by googling was https://lwn.net/Articles/517251/ Jeff -- To unsubscribe from this list: send the line "unsubscribe

Re: [x86] copy_from{to}_user question

On Mon, Aug 24, 2015 at 03:52:11PM +0800, yalin wang wrote: i am not clear about what is STAC / SMAP ? could you give me a link for understanding ? the first item I found by googling was https://lwn.net/Articles/517251/ Jeff -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH 1/1] x86: replace RDRAND forced-reseed with simple sanity check

On Fri, Jul 31, 2015 at 11:27:39AM -0400, Len Brown wrote: > if (!cpu_has(c, X86_FEATURE_RDRAND)) > - return; /* Nothing to do */ > + return; Why remove this comment? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [PATCH 1/1] x86: replace RDRAND forced-reseed with simple sanity check

On Fri, Jul 31, 2015 at 11:27:39AM -0400, Len Brown wrote: if (!cpu_has(c, X86_FEATURE_RDRAND)) - return; /* Nothing to do */ + return; Why remove this comment? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a

Re: make -jN (n>1) ineffective in 4.2.0-rc on AMD Phenom

GNU Make 4.1 has a problem that causes it to be unable to use the desired level of parallelism. Two people have reported that reverting a commit which changes from fork to vfork "fixes" it. (i'm one of them, unfortunately posting as anonymous in the tracker). Hoewver, if you are also seeing the

Re: make -jN (n1) ineffective in 4.2.0-rc on AMD Phenom

GNU Make 4.1 has a problem that causes it to be unable to use the desired level of parallelism. Two people have reported that reverting a commit which changes from fork to vfork fixes it. (i'm one of them, unfortunately posting as anonymous in the tracker). Hoewver, if you are also seeing the

Re: [PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol

On Wed, Jun 17, 2015 at 04:41:10PM -0700, Yannick Brosseau wrote: > When using a map file from a JIT, due to memory reuse, we can > obtain multiple symbols with the same start address but a different > length. Is there some reason it's impossible for the reused memory to have the same length /

Re: [PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol

On Wed, Jun 17, 2015 at 04:41:10PM -0700, Yannick Brosseau wrote: When using a map file from a JIT, due to memory reuse, we can obtain multiple symbols with the same start address but a different length. Is there some reason it's impossible for the reused memory to have the same length / end

Re: [PATCH 1/3] dt-bindings: Add Raspberry Pi compatible string for watchdog

On Tue, Jun 09, 2015 at 12:21:43PM +0200, Noralf Trønnes wrote: > The Raspberry Pi has changed how it's firmware detects a poweroff trivial typo, should be "its" .. just in case this can be fixed before it lands in a tree. Jeff -- To unsubscribe from this

Re: [PATCH 1/3] dt-bindings: Add Raspberry Pi compatible string for watchdog

On Tue, Jun 09, 2015 at 12:21:43PM +0200, Noralf Trønnes wrote: The Raspberry Pi has changed how it's firmware detects a poweroff trivial typo, should be its .. just in case this can be fixed before it lands in a tree. Jeff -- To unsubscribe from this

Re: [PATCH v2 2/2] kprobes/x86: Use 16 bytes for each instruction slot again

On Wed, Jun 03, 2015 at 10:54:11AM +0300, Eugene Shatokhin wrote: > --- a/kernel/kprobes.c > +++ b/kernel/kprobes.c > @@ -57,7 +57,6 @@ > #define KPROBE_HASH_BITS 6 > #define KPROBE_TABLE_SIZE (1 << KPROBE_HASH_BITS) > > - > /* > * Some oddball architectures like 64bit powerpc have function

Re: [PATCH v2 2/2] kprobes/x86: Use 16 bytes for each instruction slot again

On Wed, Jun 03, 2015 at 10:54:11AM +0300, Eugene Shatokhin wrote: --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -57,7 +57,6 @@ #define KPROBE_HASH_BITS 6 #define KPROBE_TABLE_SIZE (1 KPROBE_HASH_BITS) - /* * Some oddball architectures like 64bit powerpc have function

Re: [PATCH v2] x86/asm/entry/64: Use shorter MOVs from segmers registers

x86/asm/entry/64: Use shorter MOVs from segmers registers ^^^ trivial typo in the summary (should be "segment)? Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [̈́PATCHv5 00/12] usb: ulpi bus

Yes, the subject line has a [ followed by the unicode character 'combining greek dialytika tonos' which to these american eyes puts a little smudge on top of the [.. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [̈́PATCHv5 00/12] usb: ulpi bus

Yes, the subject line has a [ followed by the unicode character 'combining greek dialytika tonos' which to these american eyes puts a little smudge on top of the [.. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org

Re: [PATCH v2] x86/asm/entry/64: Use shorter MOVs from segmers registers

x86/asm/entry/64: Use shorter MOVs from segmers registers ^^^ trivial typo in the summary (should be segment)? Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org

Re: [PATCH] xtensa: Fix execdomain removal

On Sat, Apr 11, 2015 at 07:19:51PM -0700, Guenter Roeck wrote: > The removal of exexdomain changes pointer offsets into the thread_info > structure. ... > -#define TI_EXEC_DOMAIN0x0004 > -#define TI_FLAGS 0x0008 > +#define TI_FLAGS 0x0004 Hmm. If these have to be

Re: [PATCH] xtensa: Fix execdomain removal

On Sat, Apr 11, 2015 at 07:19:51PM -0700, Guenter Roeck wrote: The removal of exexdomain changes pointer offsets into the thread_info structure. ... -#define TI_EXEC_DOMAIN0x0004 -#define TI_FLAGS 0x0008 +#define TI_FLAGS 0x0004 Hmm. If these have to be

kcalloc/kmalloc_array could BUILD_BUG_ON for too-big constant arguments (was Re: [PATCH] [RESEND] aic7xxx: replace kmalloc/memset by kzalloc)

The following is a sketch of how a macro kcalloc could BUILD_BUG_ON for overflows of two compile-time operands, or call "kcalloc_variable" for nonconstant arguments. Tested on gcc 4.7.2 only, since it's what I had to hand. I didn't do any testing beyond checking that fn2 didn't build, and that

kcalloc/kmalloc_array could BUILD_BUG_ON for too-big constant arguments (was Re: [PATCH] [RESEND] aic7xxx: replace kmalloc/memset by kzalloc)

The following is a sketch of how a macro kcalloc could BUILD_BUG_ON for overflows of two compile-time operands, or call kcalloc_variable for nonconstant arguments. Tested on gcc 4.7.2 only, since it's what I had to hand. I didn't do any testing beyond checking that fn2 didn't build, and that

Re: [PATCH v2 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

[for just patch 1/4; I didn't look as closely at the others] Reviewed-by: Jeff Epler ...with one half of a caveat (rounded up?): Like most or all of the originals, and like DIV_ROUND_CLOSEST just above it in kernel.h, the new code gives an incorrect answer if the temporary overflows

Re: [PATCH v2 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

[for just patch 1/4; I didn't look as closely at the others] Reviewed-by: Jeff Epler jep...@unpythonic.net ...with one half of a caveat (rounded up?): Like most or all of the originals, and like DIV_ROUND_CLOSEST just above it in kernel.h, the new code gives an incorrect answer if the temporary

Re: [PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote: > +/* > + * Same as above but for u64 dividends. divisor must be a 32-bit > + * number. > + */ > +#define DIV_ROUND_CLOSEST_ULL(x, divisor)( \ > +{\ > + unsigned long

Re: [PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote: +/* + * Same as above but for u64 dividends. divisor must be a 32-bit + * number. + */ +#define DIV_ROUND_CLOSEST_ULL(x, divisor)( \ +{\ + unsigned long long _tmp

Re: [PATCH] afs: kstrdup() memory handling

On Sat, Mar 21, 2015 at 01:13:59PM -0400, Sanidhya Kashyap wrote: > Handling kstrdup() failure in case of memory pressure even > for new_opts. > > Signed-off-by: Sanidhya Kashyap Reviewed-by: Jeff Epler > --- > fs/afs/super.c | 6 +- > 1 file changed, 5 inse

Re: [PATCH] afs: kstrdup() memory handling

On Sat, Mar 21, 2015 at 12:50:09PM -0400, Sanidhya Kashyap wrote: > + if (new_opts) > + goto error_out; Missing "!"? Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] afs: kstrdup() memory handling

On Sat, Mar 21, 2015 at 12:50:09PM -0400, Sanidhya Kashyap wrote: + if (new_opts) + goto error_out; Missing !? Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] afs: kstrdup() memory handling

On Sat, Mar 21, 2015 at 01:13:59PM -0400, Sanidhya Kashyap wrote: Handling kstrdup() failure in case of memory pressure even for new_opts. Signed-off-by: Sanidhya Kashyap sanidhya.gat...@gmail.com Reviewed-by: Jeff Epler jep...@unpythonic.net --- fs/afs/super.c | 6 +- 1 file

Re: [PATCH v1] lib/vsprintf.c: Even faster decimal conversion

On Thu, Mar 12, 2015 at 07:08:35PM -0500, Jeff Epler wrote: > Since you asked about big-endian systems I also built your test program > for the armeb architecture -- which involved hacking up the test harness > fairly heavily to not require libc -- and ran the result in qemu. It e

Re: [PATCH v1] lib/vsprintf.c: Even faster decimal conversion

Since you asked about big-endian systems I also built your test program for the armeb architecture -- which involved hacking up the test harness fairly heavily to not require libc -- and ran the result in qemu. Actually, it hasn't finished after 2 hours of (qemu) CPU time, but I can tell from the

Re: [PATCH v1] lib/vsprintf.c: Even faster decimal conversion

On Wed, Mar 11, 2015 at 12:01:11AM +0100, Rasmus Villemoes wrote: > Test and verification code on github > . It would be nice if someone could > verify the code on architectures other than x86 - in particular, I > believe it _should_ work on big-endian, but I

Re: [PATCH v1] lib/vsprintf.c: Even faster decimal conversion

On Wed, Mar 11, 2015 at 12:01:11AM +0100, Rasmus Villemoes wrote: Test and verification code on github https://github.com/Villemoes/dec. It would be nice if someone could verify the code on architectures other than x86 - in particular, I believe it _should_ work on big-endian, but I have no

Re: [PATCH v1] lib/vsprintf.c: Even faster decimal conversion

Since you asked about big-endian systems I also built your test program for the armeb architecture -- which involved hacking up the test harness fairly heavily to not require libc -- and ran the result in qemu. Actually, it hasn't finished after 2 hours of (qemu) CPU time, but I can tell from the

Re: [PATCH v1] lib/vsprintf.c: Even faster decimal conversion

On Thu, Mar 12, 2015 at 07:08:35PM -0500, Jeff Epler wrote: Since you asked about big-endian systems I also built your test program for the armeb architecture -- which involved hacking up the test harness fairly heavily to not require libc -- and ran the result in qemu. It eventually finished

Re: [PATCH] Input: psmouse - when comparing PNP IDs ignore case

On Fri, Feb 27, 2015 at 04:18:52PM -0800, Dmitry Torokhov wrote: > PNP IDs are supposed to be case-insensitive and so we should compare > them as such. Have specific systems popped up which need this fix, or is it just in the interests of being correct? If there are specific system(s) that are

Re: [PATCH] Input: psmouse - when comparing PNP IDs ignore case

On Fri, Feb 27, 2015 at 04:18:52PM -0800, Dmitry Torokhov wrote: PNP IDs are supposed to be case-insensitive and so we should compare them as such. Have specific systems popped up which need this fix, or is it just in the interests of being correct? If there are specific system(s) that are

Re: [PATCH v2 2/3] lib/string_helpers.c: Refactor string_escape_mem

[discussing the repeated three-line idiom] > if (out < end) > *out = '\\'; > ++out; Instead of open-coding this each time, perhaps it would be appropriate to define a macro to possibly put a character and also advance the pointer. Assuming that the locals are consistently "out" and "end",

Re: [PATCH v2 2/3] lib/string_helpers.c: Refactor string_escape_mem

[discussing the repeated three-line idiom] if (out end) *out = '\\'; ++out; Instead of open-coding this each time, perhaps it would be appropriate to define a macro to possibly put a character and also advance the pointer. Assuming that the locals are consistently out and end, something

Re: [PATCH] lib/kstrtox.c clean kstrtoll function

On Fri, Jan 23, 2015 at 06:55:36PM +0530, Anshul Garg wrote: > if (((long long)tmp < LLONG_MIN) || ((long long)tmp > LLONG_MAX) ) > + return -ERANGE; This proposed code is still wrong (-ERANGE can never be returned by this statement). It may be best to leave the code alone, rather than propose

Re: [PATCH] lib/kstrtox.c clean kstrtoll function

On Fri, Jan 23, 2015 at 06:55:36PM +0530, Anshul Garg wrote: if (((long long)tmp LLONG_MIN) || ((long long)tmp LLONG_MAX) ) + return -ERANGE; This proposed code is still wrong (-ERANGE can never be returned by this statement). It may be best to leave the code alone, rather than propose more

Re: [PATCH] lib/kstrtox.c clean kstrtoll function

On Thu, Jan 22, 2015 at 05:54:10AM -0800, Anshul Garg wrote: > - if ((long long)(-tmp) >= 0) > - return -ERANGE; > - *res = -tmp; ... > + if ((long long)tmp < 0) > + return -ERANGE; > + *res = sign * tmp; I don't believe overflow

Re: [PATCH] lib/kstrtox.c clean kstrtoll function

On Thu, Jan 22, 2015 at 05:54:10AM -0800, Anshul Garg wrote: - if ((long long)(-tmp) = 0) - return -ERANGE; - *res = -tmp; ... + if ((long long)tmp 0) + return -ERANGE; + *res = sign * tmp; I don't believe overflow handling is

Re: What are these weird line-noise signatures?

On Mon, Jan 05, 2015 at 10:19:01PM -0500, Peter Hurley wrote: > Paul's message in base64-encoded. > > The scramble you see at the end when the message is decoded > is the majordomo signature added in plaintext, decoded as if > it were base64. Aha. I'm glad to have an explanation -- thank you.

Re: What are these weird line-noise signatures?

On Mon, Jan 05, 2015 at 10:19:01PM -0500, Peter Hurley wrote: Paul's message in base64-encoded. The scramble you see at the end when the message is decoded is the majordomo signature added in plaintext, decoded as if it were base64. Aha. I'm glad to have an explanation -- thank you. Jeff

What are these weird line-noise signatures?

I have seen similar "signatures" that have the appearance of good old fashioned line noise, such as in this recent message from Paul Zimmerman (but not in all of his messages either!): On Tue, Jan 06, 2015 at 01:23:30AM +, Paul Zimmerman wrote: [real content snipped] > -- > Paul > >

What are these weird line-noise signatures?

I have seen similar signatures that have the appearance of good old fashioned line noise, such as in this recent message from Paul Zimmerman (but not in all of his messages either!): On Tue, Jan 06, 2015 at 01:23:30AM +, Paul Zimmerman wrote: [real content snipped] -- Paul

Re: [PATCH] adjtimex: PPM scaling is by 2^-16

ly above). With line-wrapped fix, consider it Reviewed-by: Jeff Epler hm, as a separate issue, "ppm" seems to typically be written in lowercase. see e.g., http://en.wikipedia.org/wiki/Parts-per_notation Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [PATCH] adjtimex: PPM scaling is by 2^-16

, this is likely to be unclear to first-time readers and that section should clear it up nicely. Giving the definition of PPM as parts per million is good too. However, the patch got line-wrapped again (I fixed it manually above). With line-wrapped fix, consider it Reviewed-by: Jeff Epler jep

[PATCH] adjtimex: PPM scaling is by 2^-16

Signed-off-by: Jeff Epler --- Like Laurent Georget, I found by reading ntpd source the scale is 2^16 (i.e., 1 ~= 1.5e-5 ppm, 65536 = 1ppm) Perhaps a wording like the following is suitable. man2/adjtimex.2 | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/man2/adjtimex

[PATCH] adjtimex: PPM scaling is by 2^-16

Signed-off-by: Jeff Epler jep...@unpythonic.net --- Like Laurent Georget, I found by reading ntpd source the scale is 2^16 (i.e., 1 ~= 1.5e-5 ppm, 65536 = 1ppm) Perhaps a wording like the following is suitable. man2/adjtimex.2 | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff

Re: [PATCH] arch: tile: kernel: kgdb.c: Use memcpy() instead of pointer copy one by one

On Wed, Nov 12, 2014 at 11:43:08PM +0800, Chen Gang wrote: > > (I assume the > > compiler could do things like replace an intended load from memory with > > a constant load or even no load at all) > > > > Excuse me, my English is not quite

Re: [PATCH v2] virtio_balloon: Convert "vballon" kthread into a workqueue

Trivial typo "vballon" should be "vballoon" in subject (and in changelog, leak_ballon should be leak_balloon) Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] arch: tile: kernel: kgdb.c: Use memcpy() instead of pointer copy one by one

It seems there's additional background required to understand the diagnostic: asm/ptrace.h has struct pt_regs { /* tp, sp, and lr must immediately follow regs[] for aliasing. */ pt_reg_t regs[53]; pt_reg_t tp;/* aliases regs[TREG_TP] */ pt_reg_t sp;

Re: [PATCH] arch: tile: kernel: kgdb.c: Use memcpy() instead of pointer copy one by one

It seems there's additional background required to understand the diagnostic: asm/ptrace.h has struct pt_regs { /* tp, sp, and lr must immediately follow regs[] for aliasing. */ pt_reg_t regs[53]; pt_reg_t tp;/* aliases regs[TREG_TP] */ pt_reg_t sp;

Re: [PATCH v2] virtio_balloon: Convert vballon kthread into a workqueue

Trivial typo vballon should be vballoon in subject (and in changelog, leak_ballon should be leak_balloon) Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] arch: tile: kernel: kgdb.c: Use memcpy() instead of pointer copy one by one

On Wed, Nov 12, 2014 at 11:43:08PM +0800, Chen Gang wrote: (I assume the compiler could do things like replace an intended load from memory with a constant load or even no load at all) Excuse me, my English is not quite well, I can

Re: [PATCH] PCI: fix name of 'enable' sysfs file

is patch fixes that issue by renaming the file back. > > Reported-by: Jeff Epler > Cc: stable # 3.13 > Signed-off-by: Greg Kroah-Hartman Tested-by: Jeff Epler (with the caveat that, since LinuxCNC uses the -rt kernel, I tested this change manually backported to 3.14-rt) Thanks agai

Re: incompatible pci sysfs change since 3.12 (5136b2da770d)

On Thu, Oct 30, 2014 at 09:30:53AM -0700, Greg Kroah-Hartman wrote: > I've now sent a patch that should fix this. If you could verify it, I'd > appreciate it. Will test. Thank you. The patch sure looks plausible. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: incompatible pci sysfs change since 3.12 (5136b2da770d)

On Thu, Oct 30, 2014 at 09:30:53AM -0700, Greg Kroah-Hartman wrote: I've now sent a patch that should fix this. If you could verify it, I'd appreciate it. Will test. Thank you. The patch sure looks plausible. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in

Re: [PATCH] PCI: fix name of 'enable' sysfs file

that issue by renaming the file back. Reported-by: Jeff Epler jep...@unpythonic.net Cc: stable sta...@vger.kernel.org # 3.13 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Tested-by: Jeff Epler jep...@unpythonic.net (with the caveat that, since LinuxCNC uses the -rt kernel, I

Re: incompatible pci sysfs change since 3.12 (5136b2da770d)

On Wed, Oct 29, 2014 at 05:36:57PM -0700, Greg Kroah-Hartman wrote: > Ugh, that's my fault, I made a typo and should not have renamed the > sysfs file, very sorry about that. > > I'll work on making up a patch to fix this and get it into the stable > kernels so that you don't have to have a

incompatible pci sysfs change since 3.12 (5136b2da770d)

Hi. I am an author of LinuxCNC, a GPL'd CNC control for Linux. Recently we added support for userspace PCI drivers. This worked with kernel 3.2 but doesn't with kernel 3.16. The software fails early with Failed to open "/sys/devices/pci:00/.../enable" (Permission denied) This appears

incompatible pci sysfs change since 3.12 (5136b2da770d)

Hi. I am an author of LinuxCNC, a GPL'd CNC control for Linux. Recently we added support for userspace PCI drivers. This worked with kernel 3.2 but doesn't with kernel 3.16. The software fails early with Failed to open /sys/devices/pci:00/.../enable (Permission denied) This appears to

Re: incompatible pci sysfs change since 3.12 (5136b2da770d)

On Wed, Oct 29, 2014 at 05:36:57PM -0700, Greg Kroah-Hartman wrote: Ugh, that's my fault, I made a typo and should not have renamed the sysfs file, very sorry about that. I'll work on making up a patch to fix this and get it into the stable kernels so that you don't have to have a

Re: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for do_adjtimex()

On Tue, Oct 21, 2014 at 03:18:58AM +, Thomas Shao wrote: > In some situation, the user is not able to enable guest VM to sync with > external > time source, like NTP. But the host is still synced with a trusted time > source. > In this case, host-guest time synchronization is useful. It's

Re: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for do_adjtimex()

On Tue, Oct 21, 2014 at 03:18:58AM +, Thomas Shao wrote: In some situation, the user is not able to enable guest VM to sync with external time source, like NTP. But the host is still synced with a trusted time source. In this case, host-guest time synchronization is useful. It's

Re: [PATCH] x86: Clean up stack access code in irq_32.c

It looks like the proposed variant still miscompiles in clang 3.4 and 3.5, the two versions I had handy to test. I extracted your code to a simple standalone C translation unit and inspected various compilers' results via objdump. // cut here for cso.c struct thread_info { long l[32]; }; // who

Re: [PATCH] x86: Clean up stack access code in irq_32.c

It looks like the proposed variant still miscompiles in clang 3.4 and 3.5, the two versions I had handy to test. I extracted your code to a simple standalone C translation unit and inspected various compilers' results via objdump. // cut here for cso.c struct thread_info { long l[32]; }; // who

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

OK, my original reading of the mixing code was not accurate. This time around, I started with the original posted tarball and turned the use of the CPU clock into a very simple and clearly bad "clock" that will provide no entropy. --- jitterentropy-0.1/jitterentropy.c 2013-02-08

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

OK, my original reading of the mixing code was not accurate. This time around, I started with the original posted tarball and turned the use of the CPU clock into a very simple and clearly bad clock that will provide no entropy. --- jitterentropy-0.1/jitterentropy.c 2013-02-08

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

On Sat, Feb 09, 2013 at 01:06:29PM -0500, Theodore Ts'o wrote: > For that reasons, what I would suggest doing first is generate a > series of outputs of jitterentropy_get_nstime() followed by > schedule(). Look and see if there is any pattern. That's the problem > with the FIPS 140-2 tests.

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

On Sat, Feb 09, 2013 at 01:06:29PM -0500, Theodore Ts'o wrote: For that reasons, what I would suggest doing first is generate a series of outputs of jitterentropy_get_nstime() followed by schedule(). Look and see if there is any pattern. That's the problem with the FIPS 140-2 tests. Passing

Re: [Patch] performance enhancement for simple_strtoul

On Wed, Dec 20, 2000 at 09:09:03AM -0500, Steve Grubb wrote: > Hello, > > The following patch is a faster implementation of the simple_strtoul > function. [snip] Why not preserve the existing code for bases other than 8, 10, and 16? Admittedly, the only other case that is likely to be used

Re: [Patch] performance enhancement for simple_strtoul

On Wed, Dec 20, 2000 at 09:09:03AM -0500, Steve Grubb wrote: Hello, The following patch is a faster implementation of the simple_strtoul function. [snip] Why not preserve the existing code for bases other than 8, 10, and 16? Admittedly, the only other case that is likely to be used would be

Re: strange directory problem

On Wed, Dec 13, 2000 at 02:13:51PM +0100, Gabor Lenart wrote: > Hi, > > lgb@vega:~$ uname -a > Linux vega 2.2.18pre24 #1 Thu Dec 7 14:08:36 CET 2000 i686 unknown > > I created a directory from shell (bash). The next ls didn't show it, > I had to type ls second time too to get the changes. Is it

Re: strange directory problem

On Wed, Dec 13, 2000 at 02:13:51PM +0100, Gabor Lenart wrote: Hi, lgb@vega:~$ uname -a Linux vega 2.2.18pre24 #1 Thu Dec 7 14:08:36 CET 2000 i686 unknown I created a directory from shell (bash). The next ls didn't show it, I had to type ls second time too to get the changes. Is it a

Re: Path: for oom_kill.c

On Mon, Dec 04, 2000 at 02:57:34PM -0200, Rik van Riel wrote: > On Sat, 2 Dec 2000, hugang wrote: > > > Hello all: > > > > old> points = p->mm->total_vm; > > > > change to ---> points = p->pid; > > Ummm, what exactly do you want to achieve with this? I suspect that

Re: Path: for oom_kill.c

On Mon, Dec 04, 2000 at 02:57:34PM -0200, Rik van Riel wrote: On Sat, 2 Dec 2000, hugang wrote: Hello all: old points = p-mm-total_vm; change to --- points = p-pid; Ummm, what exactly do you want to achieve with this? I suspect that hugang whishes to

Re: Octal vs. Hex war o' death

On Wed, Nov 29, 2000 at 04:27:04PM -0700, Ian S. Nelson wrote: > c) octals were invented for UNIX file permissions and not > programming You must be joking. Read much history of computing? Or alt.folklore.computers? Octal was very natural for 18- and 36-bit machines, after all. Jeff - To

Re: Octal vs. Hex war o' death

On Wed, Nov 29, 2000 at 04:27:04PM -0700, Ian S. Nelson wrote: c) octals were invented for UNIX file permissions and not programming You must be joking. Read much history of computing? Or alt.folklore.computers? Octal was very natural for 18- and 36-bit machines, after all. Jeff - To

Re: 2.4.0-test11(-ac4)/i386 configure bug

On Sun, Nov 26, 2000 at 04:38:01PM +, Tim Waugh wrote: > On Sun, Nov 26, 2000 at 10:11:15AM -0600, Jeff Epler wrote: > > > (not affected by the -ac4 patch, the file in question is not touched) > > > > Parallel printer support (CONFIG_PRINTER) [N/m/?] (NEW) m &

2.4.0-test11(-ac4)/i386 configure bug

(not affected by the -ac4 patch, the file in question is not touched) Parallel printer support (CONFIG_PRINTER) [N/m/?] (NEW) m Support for console on line printer (CONFIG_LP_CONSOLE) [N/y/?] (NEW) Suggested change: --- linux-2.4.0-test11/drivers/char/Config.in.orig Sun Nov 26 10:05:10

2.4.0-test11(-ac4)/i386 configure bug

(not affected by the -ac4 patch, the file in question is not touched) Parallel printer support (CONFIG_PRINTER) [N/m/?] (NEW) m Support for console on line printer (CONFIG_LP_CONSOLE) [N/y/?] (NEW) Suggested change: --- linux-2.4.0-test11/drivers/char/Config.in.orig Sun Nov 26 10:05:10

Re: 2.4.0-test11(-ac4)/i386 configure bug

On Sun, Nov 26, 2000 at 04:38:01PM +, Tim Waugh wrote: On Sun, Nov 26, 2000 at 10:11:15AM -0600, Jeff Epler wrote: (not affected by the -ac4 patch, the file in question is not touched) Parallel printer support (CONFIG_PRINTER) [N/m/?] (NEW) m Support for console on line printer

Re: linux-2.2.18-pre19 asm/delay.h problem?

On Fri, Nov 24, 2000 at 11:15:50AM -0600, Oliver Xymoron wrote: > You could still change it to > __bug__module_is_using_a_delay_thats_too_large__please_report().. I thought that's where we started? Can we somehow use the GNU linker trick which permits a warning about e.g. gets at link time?

Re: linux-2.2.18-pre19 asm/delay.h problem?

On Fri, Nov 24, 2000 at 11:15:50AM -0600, Oliver Xymoron wrote: You could still change it to __bug__module_is_using_a_delay_thats_too_large__please_report().. I thought that's where we started? Can we somehow use the GNU linker trick which permits a warning about e.g. gets at link time? (Is

Re: Defective Red Hat Distribution poorly represents Linux

On Tue, Nov 21, 2000 at 06:17:48PM -0500, David Riley wrote: > Richard Torkar wrote: > > > > Well David, there is such a "manual". > > > > http://ftp.sunet.se/LDP/FAQ/faqs/GCC-SIG11-FAQ > > Yes. And if you ask the average new Linux user if they've read it, I > doubt you'll get a "yes". My

Re: Defective Red Hat Distribution poorly represents Linux

On Tue, Nov 21, 2000 at 04:08:26PM -0500, David Riley wrote: > Windoze is not the only OS to handle bad hardware better than Linux. On > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept > causing random bus-type errors in Linux. Same as when I accidentally > (long story)

  1   2   >