Re: WireGuard to port to existing Crypto API

Are there going to be two branches, one for using the current API and one using Zinc?

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Sat, Dec 30, 2017 at 00:30:32 +0800, weiping zhang wrote: 1. Add proper SELINUX policy that give permission to mdadm for debugfs. 2. Split mdadm into 2 part, Firstly, user proccess mdadm trigger a kwork, secondly kwork will create gendisk)and mdadm wait it

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Sat, Dec 30, 2017 at 00:30:32 +0800, weiping zhang wrote: 1. Add proper SELINUX policy that give permission to mdadm for debugfs. 2. Split mdadm into 2 part, Firstly, user proccess mdadm trigger a kwork, secondly kwork will create gendisk)and mdadm wait it done, Like following: diff --git

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 22, 2017 at 21:20:10 +0800, weiping zhang <zwp10...@gmail.com> wrote: 2017-12-22 12:53 GMT+08:00 Bruno Wolff III <br...@wolff.to>: On Thu, Dec 21, 2017 at 17:16:03 -0600, Bruno Wolff III <br...@wolff.to> wrote: Enforcing mode alone isn't enough as I tested th

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 22, 2017 at 21:20:10 +0800, weiping zhang wrote: 2017-12-22 12:53 GMT+08:00 Bruno Wolff III : On Thu, Dec 21, 2017 at 17:16:03 -0600, Bruno Wolff III wrote: Enforcing mode alone isn't enough as I tested that one one machine at home and it didn't trigger the problem. I'll try

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 17:16:03 -0600, Bruno Wolff III <br...@wolff.to> wrote: Enforcing mode alone isn't enough as I tested that one one machine at home and it didn't trigger the problem. I'll try another machine late tonight. I got the problem to occur on my i686 machine when b

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 17:16:03 -0600, Bruno Wolff III wrote: Enforcing mode alone isn't enough as I tested that one one machine at home and it didn't trigger the problem. I'll try another machine late tonight. I got the problem to occur on my i686 machine when booting in enforcing mode

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 12:15:31 -0600, Bruno Wolff III <br...@wolff.to> wrote: One important thing I have just found is that it looks like the problem only happens when booting in enforcing mode. If I boot in permissive mode it does not happen. My home machines are currently set t

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 12:15:31 -0600, Bruno Wolff III wrote: One important thing I have just found is that it looks like the problem only happens when booting in enforcing mode. If I boot in permissive mode it does not happen. My home machines are currently set to boot in permissive mode

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 10:02:15 -0700, Jens Axboe <ax...@kernel.dk> wrote: On 12/21/17 9:42 AM, Bruno Wolff III wrote: On Thu, Dec 21, 2017 at 23:48:19 +0800, weiping zhang <zwp10...@gmail.com> wrote: output you want. I never saw it for any kernels I compiled myself. Only

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 10:02:15 -0700, Jens Axboe wrote: On 12/21/17 9:42 AM, Bruno Wolff III wrote: On Thu, Dec 21, 2017 at 23:48:19 +0800, weiping zhang wrote: output you want. I never saw it for any kernels I compiled myself. Only when I test kernels built by Fedora do I see it. see

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 23:48:19 +0800, weiping zhang wrote: output you want. I never saw it for any kernels I compiled myself. Only when I test kernels built by Fedora do I see it. see it every boot ? I don't look every boot. The warning gets scrolled of the screen.

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 23:48:19 +0800, weiping zhang wrote: output you want. I never saw it for any kernels I compiled myself. Only when I test kernels built by Fedora do I see it. see it every boot ? I don't look every boot. The warning gets scrolled of the screen. Once I see the CPU

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 23:31:40 +0800, weiping zhang wrote: does every time boot fail can trigger WANRING in device_add_disk ? Not that I see. But the message could scroll off the screen. The boot gets far enough that systemd copies over dmesg output to permanent

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 23:31:40 +0800, weiping zhang wrote: does every time boot fail can trigger WANRING in device_add_disk ? Not that I see. But the message could scroll off the screen. The boot gets far enough that systemd copies over dmesg output to permanent storage that I can see on

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 22:01:33 +0800, weiping zhang wrote: Hi, how do you do bisect ?build all kernel commit one by one ? as you did before: https://bugzilla.redhat.com/show_bug.cgi?id=1520982 I just did the one bisect using Linus' tree. After each build, I would do a

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 21, 2017 at 22:01:33 +0800, weiping zhang wrote: Hi, how do you do bisect ?build all kernel commit one by one ? as you did before: https://bugzilla.redhat.com/show_bug.cgi?id=1520982 I just did the one bisect using Linus' tree. After each build, I would do a test boot and see if

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

After today, I won't have physical access to the problem machine until January 2nd. So if you guys have any testing suggestions I need them soon if they are to get done before my vacation. I do plan to try booting to level 1 to see if I can get a login prompt that might facilitate testing. The

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

After today, I won't have physical access to the problem machine until January 2nd. So if you guys have any testing suggestions I need them soon if they are to get done before my vacation. I do plan to try booting to level 1 to see if I can get a login prompt that might facilitate testing. The

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Tue, Dec 19, 2017 at 10:24:52 -0800, Shaohua Li wrote: Not sure if this is MD related, but could you please check if this debug patch changes anything? The system still had cpu hangs. I've attached dmesg output saved by systemd and retrieved after booting with a pre-rc2

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Tue, Dec 19, 2017 at 10:24:52 -0800, Shaohua Li wrote: Not sure if this is MD related, but could you please check if this debug patch changes anything? The system still had cpu hangs. I've attached dmesg output saved by systemd and retrieved after booting with a pre-rc2 kernel. -- Logs

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Tue, Dec 19, 2017 at 10:24:52 -0800, Shaohua Li wrote: Not sure if this is MD related, but could you please check if this debug patch changes anything? I'm doing a build now. I do use md to mirror disk partitions between two disks. I do that on another machine that

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Tue, Dec 19, 2017 at 10:24:52 -0800, Shaohua Li wrote: Not sure if this is MD related, but could you please check if this debug patch changes anything? I'm doing a build now. I do use md to mirror disk partitions between two disks. I do that on another machine that doesn't exhibit the

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Sun, Dec 17, 2017 at 21:43:50 +0800, weiping zhang wrote: Hi, thanks for testing, I think you first reproduce this issue(got WARNING at device_add_disk) by your own build, then add my debug patch. The problem is still in rc4. Reverting the commit still fixes the

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Sun, Dec 17, 2017 at 21:43:50 +0800, weiping zhang wrote: Hi, thanks for testing, I think you first reproduce this issue(got WARNING at device_add_disk) by your own build, then add my debug patch. The problem is still in rc4. Reverting the commit still fixes the problem. I tested that

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Sun, Dec 17, 2017 at 21:43:50 +0800, weiping zhang wrote: Hi, thanks for testing, I think you first reproduce this issue(got WARNING at device_add_disk) by your own build, then add my debug patch. I'm going to try testing warnings with a kernel I've built, to try to

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Sun, Dec 17, 2017 at 21:43:50 +0800, weiping zhang wrote: Hi, thanks for testing, I think you first reproduce this issue(got WARNING at device_add_disk) by your own build, then add my debug patch. I'm going to try testing warnings with a kernel I've built, to try to determine if warnings

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Sun, Dec 17, 2017 at 21:43:50 +0800, weiping zhang wrote: Hi, thanks for testing, I think you first reproduce this issue(got WARNING at device_add_disk) by your own build, then add my debug patch. No, the first log (that Laura copied) was from the Fedora bug and it was

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Sun, Dec 17, 2017 at 21:43:50 +0800, weiping zhang wrote: Hi, thanks for testing, I think you first reproduce this issue(got WARNING at device_add_disk) by your own build, then add my debug patch. No, the first log (that Laura copied) was from the Fedora bug and it was from a Fedora

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 13:51:22 -0600, Bruno Wolff III <br...@wolff.to> wrote: I do not know what is different. Do you have any ideas? Most likely I won't be able to test any more kernels until Monday (unless I can use most of my most recent build over again very soon). The .config

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 13:51:22 -0600, Bruno Wolff III wrote: I do not know what is different. Do you have any ideas? Most likely I won't be able to test any more kernels until Monday (unless I can use most of my most recent build over again very soon). The .config looks like it should

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 22:02:20 +0800, weiping zhang wrote: Sorry to let you confuse, WARN_ON means we catch log as following: WARNING: CPU: 3 PID: 3486 at block/genhd.c:680 device_add_disk+0x3d9/0x460 I do not get this warning for any of the kernels I build, whether

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 22:02:20 +0800, weiping zhang wrote: Sorry to let you confuse, WARN_ON means we catch log as following: WARNING: CPU: 3 PID: 3486 at block/genhd.c:680 device_add_disk+0x3d9/0x460 I do not get this warning for any of the kernels I build, whether from Linus' tree or

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 09:18:56 -0800, Laura Abbott wrote: You can see the trees Fedora produces at https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git which includes the configs (you want to look at the ones withtout - debug) Thanks. I found it a little

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 09:18:56 -0800, Laura Abbott wrote: You can see the trees Fedora produces at https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git which includes the configs (you want to look at the ones withtout - debug) Thanks. I found it a little while ago and am

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 22:02:20 +0800, weiping zhang wrote: Yes, please help reproduce this issue include my debug patch. Reproduce means we can see WARN_ON in device_add_disk caused by failure of bdi_register_owner. I'm not sure why yet, but I'm only getting the

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 22:02:20 +0800, weiping zhang wrote: Yes, please help reproduce this issue include my debug patch. Reproduce means we can see WARN_ON in device_add_disk caused by failure of bdi_register_owner. I'm not sure why yet, but I'm only getting the warning message you want

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 10:04:32 +0800, weiping zhang wrote: I just want to know WARN_ON WHAT in device_add_disk, if bdi_register_owner return error code, it may fail at any step of following: Was that output in the original boot log? I didn't see anything there that had

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 10:04:32 +0800, weiping zhang wrote: I just want to know WARN_ON WHAT in device_add_disk, if bdi_register_owner return error code, it may fail at any step of following: Was that output in the original boot log? I didn't see anything there that had the string WARN_ON.

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 10:04:32 +0800, weiping zhang wrote: so I want see the WARN_ON as you paste before, also my DEBUG log will help to find which step fail. The previous time also journalctl for output, but maybe I used slightly different options. I'll look and see

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 10:04:32 +0800, weiping zhang wrote: so I want see the WARN_ON as you paste before, also my DEBUG log will help to find which step fail. The previous time also journalctl for output, but maybe I used slightly different options. I'll look and see if it is in the

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 09:22:21 +0800, weiping zhang wrote: Thanks your testing, but I cann't find WARN_ON in device_add_disk from this boot1.log, could you help reproduce that issue? And does this issue can be triggered at every bootup ? I don't know what you need for

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 15, 2017 at 09:22:21 +0800, weiping zhang wrote: Thanks your testing, but I cann't find WARN_ON in device_add_disk from this boot1.log, could you help reproduce that issue? And does this issue can be triggered at every bootup ? I don't know what you need for the first question.

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 14, 2017 at 18:09:27 +0800, weiping zhang wrote: It seems something wrong with bdi debugfs register, could you help test the forllowing debug patch, I add some debug log, no function change, thanks. I applied your patch to

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 14, 2017 at 18:09:27 +0800, weiping zhang wrote: It seems something wrong with bdi debugfs register, could you help test the forllowing debug patch, I add some debug log, no function change, thanks. I applied your patch to d39a01eff9af1045f6e30ff9db40310517c4b45f and there were

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 14, 2017 at 18:09:27 +0800, weiping zhang <zhangweip...@didichuxing.com> wrote: On Thu, Dec 14, 2017 at 02:24:52AM -0600, Bruno Wolff III wrote: On Wed, Dec 13, 2017 at 16:54:17 -0800, Laura Abbott <labb...@redhat.com> wrote: >Hi, > >Fedora g

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Thu, Dec 14, 2017 at 18:09:27 +0800, weiping zhang wrote: On Thu, Dec 14, 2017 at 02:24:52AM -0600, Bruno Wolff III wrote: On Wed, Dec 13, 2017 at 16:54:17 -0800, Laura Abbott wrote: >Hi, > >Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982 >of a

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Wed, Dec 13, 2017 at 16:54:17 -0800, Laura Abbott wrote: Hi, Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982 of a boot failure/bug on Linus' master (full bootlog at the bugzilla) I'm available for testing. The problem happens on my x86_64

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Wed, Dec 13, 2017 at 16:54:17 -0800, Laura Abbott wrote: Hi, Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982 of a boot failure/bug on Linus' master (full bootlog at the bugzilla) I'm available for testing. The problem happens on my x86_64 Dell Workstation,

Re: [RFC] WireGuard: next generation secure network tunnel

On Sat, Jul 02, 2016 at 01:03:17 +0200, "Jason A. Donenfeld" wrote: Hey Bruno, Sorry I didn't reply to this earlier; the message didn't make it to me somehow. I only sent it to LKML, since we had communicated separately when you helped me by making changes for the 4.7

Re: [RFC] WireGuard: next generation secure network tunnel

On Sat, Jul 02, 2016 at 01:03:17 +0200, "Jason A. Donenfeld" wrote: Hey Bruno, Sorry I didn't reply to this earlier; the message didn't make it to me somehow. I only sent it to LKML, since we had communicated separately when you helped me by making changes for the 4.7 kernel, I didn't

Re: [RFC] WireGuard: next generation secure network tunnel

On Tue, Jun 28, 2016 at 16:49:18 +0200, "Jason A. Donenfeld" wrote: Today I'm releasing WireGuard, an encrypted and authenticated tunneling virtual interface for the kernel. It uses next-generation I tried this out on 4.7 kernels and it seemed to work OK. I can't tell

Re: [RFC] WireGuard: next generation secure network tunnel

On Tue, Jun 28, 2016 at 16:49:18 +0200, "Jason A. Donenfeld" wrote: Today I'm releasing WireGuard, an encrypted and authenticated tunneling virtual interface for the kernel. It uses next-generation I tried this out on 4.7 kernels and it seemed to work OK. I can't tell about security, but

Re: Regression in v4.5-rc1, bisected to commit 39bfcd5235e0 ("drm/i915: more virtual south bridge detection")

On Mon, Jan 25, 2016 at 03:52:25 +0100, Bjørn Mork wrote: Hello, my oldish Thinkpad X301 only wanted to show a blank screen in v4.5-rc1. Bisecting resulted in: drm/i915: more virtual south bridge detection I am likely seeing the same problem on a Dell laptop. I haven't finished my

Re: Regression in v4.5-rc1, bisected to commit 39bfcd5235e0 ("drm/i915: more virtual south bridge detection")

On Mon, Jan 25, 2016 at 03:52:25 +0100, Bjørn Mork wrote: Hello, my oldish Thinkpad X301 only wanted to show a blank screen in v4.5-rc1. Bisecting resulted in: drm/i915: more virtual south bridge detection I am likely seeing the same problem on a Dell laptop. I haven't

Re: [PATCH 0/2] Squashfs: add LZ4 compression

On Fri, Dec 12, 2014 at 13:23:19 +0100, toki clover wrote: Now, I did not see any Linux FS devs activity/response to this... What a waste of time because if those patch don't make it for this merge window, rebasing/reposting will be, again, necessary. The patches got pulled into linux-next.

Re: [PATCH 0/2] Squashfs: add LZ4 compression

On Fri, Dec 12, 2014 at 13:23:19 +0100, toki clover tokiclo...@gmail.com wrote: Now, I did not see any Linux FS devs activity/response to this... What a waste of time because if those patch don't make it for this merge window, rebasing/reposting will be, again, necessary. The patches got

Re: [PATCH 0/2] Squashfs: add LZ4 compression

On Thu, Nov 27, 2014 at 08:00:47 +, Phillip Lougher wrote: My intention is to submit them in the next kernel merge window. If you want LZ4 support in Squashfs now is a good time to publically support the inclusion of these patches. Fedora has been supporting LZ4 functionallity in

Re: [PATCH 0/2] Squashfs: add LZ4 compression

On Thu, Nov 27, 2014 at 08:00:47 +, Phillip Lougher phil...@squashfs.org.uk wrote: My intention is to submit them in the next kernel merge window. If you want LZ4 support in Squashfs now is a good time to publically support the inclusion of these patches. Fedora has been supporting LZ4

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Wed, Jul 23, 2014 at 17:11:40 +0200, Peter Zijlstra wrote: OK, so that's become the below patch. I'll feed it to Ingo if that's OK with hpa. I tested this patch on 3 machines and it continued to fix the one that was broken and didn't seem to break anything on the two that weren't

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Wed, Jul 23, 2014 at 17:11:40 +0200, Peter Zijlstra pet...@infradead.org wrote: OK, so that's become the below patch. I'll feed it to Ingo if that's OK with hpa. I tested this patch on 3 machines and it continued to fix the one that was broken and didn't seem to break anything on the two

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 16:18:55 +0200, Peter Zijlstra wrote: You can put this on top of them. I hope that this will make the pr_err() introduced in the robustify patch go away. I went to 3.16-rc6 and then reapplied three patches from your previous email messages. The dmesg output and the

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 15:35:14 +0200, Peter Zijlstra wrote: On Tue, Jul 22, 2014 at 03:26:03PM +0200, Peter Zijlstra wrote: Something like so.. anything obviously broken? Do you want me to test this change instead of, or combined with the other patch you wanted tested earlier? ---

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 11:47:40 +0200, Peter Zijlstra wrote: On Mon, Jul 21, 2014 at 06:52:12PM +0200, Peter Zijlstra wrote: On Mon, Jul 21, 2014 at 11:35:28AM -0500, Bruno Wolff III wrote: > Is there more I can do to help with this now? Or should I just wait for > patches to test?

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 12:38:57 +0200, Peter Zijlstra wrote: Could you provide the output of cpuid and cpuid -r for your machine? This code is magic and I've no idea what your machine is telling it to do :/ I am attaching both sets of output. (I also added copies to the bug report.) CPU 0:

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 12:38:57 +0200, Peter Zijlstra pet...@infradead.org wrote: Could you provide the output of cpuid and cpuid -r for your machine? This code is magic and I've no idea what your machine is telling it to do :/ I am attaching both sets of output. (I also added copies to the

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 11:47:40 +0200, Peter Zijlstra pet...@infradead.org wrote: On Mon, Jul 21, 2014 at 06:52:12PM +0200, Peter Zijlstra wrote: On Mon, Jul 21, 2014 at 11:35:28AM -0500, Bruno Wolff III wrote: Is there more I can do to help with this now? Or should I just wait for patches

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 15:35:14 +0200, Peter Zijlstra pet...@infradead.org wrote: On Tue, Jul 22, 2014 at 03:26:03PM +0200, Peter Zijlstra wrote: Something like so.. anything obviously broken? Do you want me to test this change instead of, or combined with the other patch you wanted tested

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 16:18:55 +0200, Peter Zijlstra pet...@infradead.org wrote: You can put this on top of them. I hope that this will make the pr_err() introduced in the robustify patch go away. I went to 3.16-rc6 and then reapplied three patches from your previous email messages. The

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

Is there more I can do to help with this now? Or should I just wait for patches to test? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

Is there more I can do to help with this now? Or should I just wait for patches to test? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Fri, Jul 18, 2014 at 12:16:33 +0200, Peter Zijlstra wrote: So it looks like the actual domain tree is broken, and not what we assumed it was. Could I bother you to run with the below instead? It should also print out the sched domain masks so we don't need to guess about them. The full

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Fri, Jul 18, 2014 at 11:28:14 +0200, Dietmar Eggemann wrote: Didn't see what I was looking for in your dmesg output. Did you use 'earlyprintk=keep sched_debug' I was missing a space. I'll get it on the next run. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Fri, Jul 18, 2014 at 11:28:14 +0200, Dietmar Eggemann dietmar.eggem...@arm.com wrote: Didn't see what I was looking for in your dmesg output. Did you use 'earlyprintk=keep sched_debug' I was missing a space. I'll get it on the next run. -- To unsubscribe from this list: send the line

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Fri, Jul 18, 2014 at 12:16:33 +0200, Peter Zijlstra pet...@infradead.org wrote: So it looks like the actual domain tree is broken, and not what we assumed it was. Could I bother you to run with the below instead? It should also print out the sched domain masks so we don't need to guess

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Thu, Jul 17, 2014 at 14:35:02 +0200, Peter Zijlstra wrote: In any case, can someone who can trigger this run with the below; its 'clean' for me, but supposedly you'll trigger a FAIL somewhere. I got a couple of fail messages. dmesg output is available in the bug as the following

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Thu, Jul 17, 2014 at 20:43:16 +0200, Dietmar Eggemann wrote: If you could apply the patch: https://lkml.org/lkml/2014/7/17/288 and then run it on your machine, that would give us more details, i.e. the information on which sched_group(s) and in which sched domain level (SMT and/or DIE)

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

I did a few quick boots this morning while taking a bunch of pictures. I have gone through some of them this morning and found one that shows bug on was triggered at 5850 which is from: BUG_ON(!cpumask_empty(sched_group_cpus(sg))); You can see the JPEG at:

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

I did a few quick boots this morning while taking a bunch of pictures. I have gone through some of them this morning and found one that shows bug on was triggered at 5850 which is from: BUG_ON(!cpumask_empty(sched_group_cpus(sg))); You can see the JPEG at:

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Thu, Jul 17, 2014 at 20:43:16 +0200, Dietmar Eggemann dietmar.eggem...@arm.com wrote: If you could apply the patch: https://lkml.org/lkml/2014/7/17/288 and then run it on your machine, that would give us more details, i.e. the information on which sched_group(s) and in which sched domain

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Thu, Jul 17, 2014 at 14:35:02 +0200, Peter Zijlstra pet...@infradead.org wrote: In any case, can someone who can trigger this run with the below; its 'clean' for me, but supposedly you'll trigger a FAIL somewhere. I got a couple of fail messages. dmesg output is available in the bug as

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Wed, Jul 16, 2014 at 21:17:32 +0200, Dietmar Eggemann wrote: Could you please share: cat /proc/cpuinfo and cat /proc/schedstat (kernel config w/ CONFIG_SCHEDSTATS=y) /proc/schedstat output is attached. version 15 timestamp 4294858660 cpu0 12 0 85767 30027 61826 37767 15709950719

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

Could you also put the two BUG_ON lines into build_sched_groups() [kernel/sched/core.c] wo/ the cpumask_clear() and setting sg->sgc->capacity to 0 and share the possible crash output as well? I can try a new build with this. I can probably get results back tomorrow before I leave for work. The

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Thu, Jul 17, 2014 at 01:18:36 +0200, Dietmar Eggemann wrote: So the output of $ cat /proc/sys/kernel/sched_domain/cpu*/domain*/* would be handy too. Attached and added to the bug. Just to make sure, you do have 'CONFIG_X86_32=y' and '# CONFIG_NUMA is not set' in your build? Yes. I

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Wed, Jul 16, 2014 at 21:17:32 +0200, Dietmar Eggemann wrote: Hi Bruno and Josh, From the issue, I see that the machine making trouble is an Xeon (2 processors w/ hyper-threading). Could you please share: cat /proc/cpuinfo and I have attached it to the bug and to this message. cat

Re: find_busiest_group divide error

So I tried checking out specific revisions and found 09dc4ab03936df5c5aa711d27c81283c6d09f495 is the latest good revision I can boot. The first bad revision I hit is 51f2176d74ace4c3f58579a605ef5a9720befb00. I have no idea how to fix it. I'm just a web developer/kernel tester :( Could you

Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

caffcdd8d27ba78730d5540396ce72ad022aff2c has been causing crashes early in the boot process on one of three machines I have been testing the kernel on. On that one machine it happens every boot. It happens before netconsole is functional. A partial revert of the commit fixes the problem. I do

Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

caffcdd8d27ba78730d5540396ce72ad022aff2c has been causing crashes early in the boot process on one of three machines I have been testing the kernel on. On that one machine it happens every boot. It happens before netconsole is functional. A partial revert of the commit fixes the problem. I do

Re: find_busiest_group divide error

So I tried checking out specific revisions and found 09dc4ab03936df5c5aa711d27c81283c6d09f495 is the latest good revision I can boot. The first bad revision I hit is 51f2176d74ace4c3f58579a605ef5a9720befb00. I have no idea how to fix it. I'm just a web developer/kernel tester :( Could you

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Wed, Jul 16, 2014 at 21:17:32 +0200, Dietmar Eggemann dietmar.eggem...@arm.com wrote: Hi Bruno and Josh, From the issue, I see that the machine making trouble is an Xeon (2 processors w/ hyper-threading). Could you please share: cat /proc/cpuinfo and I have attached it to the bug and

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Thu, Jul 17, 2014 at 01:18:36 +0200, Dietmar Eggemann dietmar.eggem...@arm.com wrote: So the output of $ cat /proc/sys/kernel/sched_domain/cpu*/domain*/* would be handy too. Attached and added to the bug. Just to make sure, you do have 'CONFIG_X86_32=y' and '# CONFIG_NUMA is not set'

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

Could you also put the two BUG_ON lines into build_sched_groups() [kernel/sched/core.c] wo/ the cpumask_clear() and setting sg-sgc-capacity to 0 and share the possible crash output as well? I can try a new build with this. I can probably get results back tomorrow before I leave for work. The

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On Wed, Jul 16, 2014 at 21:17:32 +0200, Dietmar Eggemann dietmar.eggem...@arm.com wrote: Could you please share: cat /proc/cpuinfo and cat /proc/schedstat (kernel config w/ CONFIG_SCHEDSTATS=y) /proc/schedstat output is attached. version 15 timestamp 4294858660 cpu0 12 0 85767 30027 61826

Re: [regression] fix 32-bit breakage in block device read(2) (was Re: 32-bit bug in iovec iterator changes)

On Mon, Jun 23, 2014 at 08:44:40 +0100, Al Viro wrote: blkdev_read_iter() wants to cap the iov_iter by the amount of data remaining to the end of device. That's what iov_iter_truncate() is for (trim iter->count if it's above the given limit). So far, so good, but the argument of

Re: [regression] fix 32-bit breakage in block device read(2) (was Re: 32-bit bug in iovec iterator changes)

On Mon, Jun 23, 2014 at 08:44:40 +0100, Al Viro v...@zeniv.linux.org.uk wrote: blkdev_read_iter() wants to cap the iov_iter by the amount of data remaining to the end of device. That's what iov_iter_truncate() is for (trim iter-count if it's above the given limit). So far, so good, but the

Re: [PATCH] kernel: replace strict_strto*() with kstrto*()

On Fri, Sep 27, 2013 at 13:18:20 -0700, Andrew Morton wrote: On Fri, 27 Sep 2013 19:53:53 +0200 Jean Delvare wrote: Andrew, On Fri, 27 Sep 2013 09:50:39 -0600, Bjorn Helgaas wrote: > There's some indication that this change might have broken handling of > signed types. See >

Re: [PATCH] kernel: replace strict_strto*() with kstrto*()

On Fri, Sep 27, 2013 at 13:18:20 -0700, Andrew Morton a...@linux-foundation.org wrote: On Fri, 27 Sep 2013 19:53:53 +0200 Jean Delvare kh...@linux-fr.org wrote: Andrew, On Fri, 27 Sep 2013 09:50:39 -0600, Bjorn Helgaas wrote: There's some indication that this change might have broken

Re: [PATCH 0/2] Squashfs: add LZ4 compression

On Tue, Jul 23, 2013 at 17:17:30 +0100, Phillip Lougher wrote: In otherwords I don't think it's wise yet to merge LZ4 onto stable, not until at least there's some positive feedback on the mailing list. Thoughts? Maybe some positive feedback? :-) I think it makes sense to tie inclusion in

Re: [PATCH 0/2] Squashfs: add LZ4 compression

On Mon, Jul 22, 2013 at 03:21:01 +0100, Phillip Lougher wrote: Hi Now that LZ4 compression support is in 3.11-rc1, I have written the following two patches for Squashfs to use it. If this gets accepted are you going to move the LZ4 changes to squashfs-tools into the stable branch? I'd

Re: [PATCH 0/2] Squashfs: add LZ4 compression

On Mon, Jul 22, 2013 at 03:21:01 +0100, Phillip Lougher phil...@squashfs.org.uk wrote: Hi Now that LZ4 compression support is in 3.11-rc1, I have written the following two patches for Squashfs to use it. If this gets accepted are you going to move the LZ4 changes to squashfs-tools into

  1   2   >