Re: clang warning: implicit conversion in intel_ddi.c:1481

[Ozgur]

01.02.2018, 21:03, "Greg KH" <g...@kroah.com>:
> On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote:
>>  Dear Rodrigo Vivi, Ville Syrjälä,
>>
>>  My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We

Hi Ozan,

why did you send e-mail to kernel development e-mail list?

>>  intend to use static analysis tools on the kernel source to identify,
>>  analyze and report issues. As a very first step, we are looking into
>>  clang compiler warnings and will then move to more sophisticated tools.
>>
>>  When compiling Linux 4.15 with clang, we have discovered that your commit
>>  2952cd6fb4cc ("drm/i915: Let's use more enum intel_dpll_id pll_id.")
>>  introduced the following warning:
>>
>>  drivers/gpu/drm/i915/intel_ddi.c:1481:30: warning: implicit conversion from 
>> enumeration type 'enum port' to different enumeration type 'enum 
>> intel_dpll_id' [-Wenum-conversion]
>>  enum intel_dpll_id pll_id = port;
>>
>>  To reproduce it, you can compile Linux 4.15 with clang with this command:
>>
>>  make HOSTCC=clang-5.0 defconfig && make -j32 HOSTCC=clang-5.0 CC=clang-5.0
>>
>>  If you don't have clang installed in your system, you can use this simple
>>  docker setup to compile the kernel with clang:
>>
>>  wget 
>> https://raw.githubusercontent.com/bulwahn/linux-kernel-analysis/master/docker/kernel-clang/Dockerfile
>>  && \
>>  docker build -t kernel-clang . && \
>>  docker run -v :/linux/ kernel-clang /bin/sh 
>> -c "cd linux && make CC=clang-5.0 clean && make HOSTCC=clang-5.0 defconfig 
>> && make -j32 HOSTCC=clang-5.0 CC=clang-5.0"
>>
>>  While we were doing our analysis on 4.15, we noticed that you already
>>  resolved this warning on linux-next with your work in commit bb911536f07e
>>  ("drm/i915: Eliminate pll->state usage from bxt_calc_pll_link()"). So,
>>  since it is resolved on linux-next and we expect that this commit will be
>>  merged in the merge window for 4.16, there is probably nothing further to
>>  do.
>>
>>  Linux 4.15 is shipped with this clang warning, but we don't see the
>>  crucial need to provide a backport commit to the stable branch for 4.15.
>>  We just wanted to inform you about our analysis of this clang warning.
>>  Ultimately the final call if you would like to address this clang warning
>>  in 4.15 is yours.
>
> Note, I have not taken "clang warning fixes" for stable kernel updates
> in the past, and I doubt I will in the future, unless the tree "builds
> clean" with clang. If it eventually gets there, then yes, I will do
> that.
>
> Note, if you are going to email this out to everyone who fixes a warning
> message, you might want to reconsider it. That's going to be a lot of
> work, and for people who have already fixed an issue, it's kind of
> pointless to just remind them of work they have done in the past, right?
>
> What is the goal of these types of emails?
>
> thanks,
>
> greg k-h

Ozgur

Re: clang warning: implicit conversion in intel_ddi.c:1481

[Ozgur]

01.02.2018, 21:03, "Greg KH" :
> On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote:
>>  Dear Rodrigo Vivi, Ville Syrjälä,
>>
>>  My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We

Hi Ozan,

why did you send e-mail to kernel development e-mail list?

>>  intend to use static analysis tools on the kernel source to identify,
>>  analyze and report issues. As a very first step, we are looking into
>>  clang compiler warnings and will then move to more sophisticated tools.
>>
>>  When compiling Linux 4.15 with clang, we have discovered that your commit
>>  2952cd6fb4cc ("drm/i915: Let's use more enum intel_dpll_id pll_id.")
>>  introduced the following warning:
>>
>>  drivers/gpu/drm/i915/intel_ddi.c:1481:30: warning: implicit conversion from 
>> enumeration type 'enum port' to different enumeration type 'enum 
>> intel_dpll_id' [-Wenum-conversion]
>>  enum intel_dpll_id pll_id = port;
>>
>>  To reproduce it, you can compile Linux 4.15 with clang with this command:
>>
>>  make HOSTCC=clang-5.0 defconfig && make -j32 HOSTCC=clang-5.0 CC=clang-5.0
>>
>>  If you don't have clang installed in your system, you can use this simple
>>  docker setup to compile the kernel with clang:
>>
>>  wget 
>> https://raw.githubusercontent.com/bulwahn/linux-kernel-analysis/master/docker/kernel-clang/Dockerfile
>>  && \
>>  docker build -t kernel-clang . && \
>>  docker run -v :/linux/ kernel-clang /bin/sh 
>> -c "cd linux && make CC=clang-5.0 clean && make HOSTCC=clang-5.0 defconfig 
>> && make -j32 HOSTCC=clang-5.0 CC=clang-5.0"
>>
>>  While we were doing our analysis on 4.15, we noticed that you already
>>  resolved this warning on linux-next with your work in commit bb911536f07e
>>  ("drm/i915: Eliminate pll->state usage from bxt_calc_pll_link()"). So,
>>  since it is resolved on linux-next and we expect that this commit will be
>>  merged in the merge window for 4.16, there is probably nothing further to
>>  do.
>>
>>  Linux 4.15 is shipped with this clang warning, but we don't see the
>>  crucial need to provide a backport commit to the stable branch for 4.15.
>>  We just wanted to inform you about our analysis of this clang warning.
>>  Ultimately the final call if you would like to address this clang warning
>>  in 4.15 is yours.
>
> Note, I have not taken "clang warning fixes" for stable kernel updates
> in the past, and I doubt I will in the future, unless the tree "builds
> clean" with clang. If it eventually gets there, then yes, I will do
> that.
>
> Note, if you are going to email this out to everyone who fixes a warning
> message, you might want to reconsider it. That's going to be a lot of
> work, and for people who have already fixed an issue, it's kind of
> pointless to just remind them of work they have done in the past, right?
>
> What is the goal of these types of emails?
>
> thanks,
>
> greg k-h

Ozgur

Re: Documentation: rapidio: move sysfs interface to ABI

[Ozgur]

08.01.2018, 12:03, "Aishwarya Pant" <aishp...@gmail.com>:
> On Mon, Jan 08, 2018 at 11:58:12AM +0300, Ozgur wrote:
>>  08.01.2018, 11:38, "Aishwarya Pant" <aishp...@gmail.com>:
>>  > Hi
>>
>>  Hello,
>>
>>  > In Documentation/rapidio/sysfs.txt, there is a description of the sysfs
>>  > interface which could be moved to Documentation/ABI (as a bus interface 
>> under
>>  > testing).
>>  >
>>  > Would such a change be useful?
>>  >
>>  > The ABI documentation format looks like the following:
>>  >
>>  > What: (the full sysfs path of the attribute)
>>  > Date: (date of creation)
>>  > KernelVersion: (kernel version it first showed up in)
>>  > Contact: (primary contact)
>>  > Description: (long description on usage)
>>
>>  Please you make the change you want after send your patch it diff format, 
>> right?
>>  I think a better decision can be made.
>
> This is the idea. If this change is acceptable, then I can make a patch and 
> send
> it for review.

Hm,

I think firstly you should send the patch then everybody checked and change is 
decided.


Regards

Ozgur

> Aishwarya
>
>>  > I am doing this in an exercise to move sysfs ABI interfaces (which are
>>  > documented) to their right place i.e. in Documentation/ABI along with the 
>> rest.
>>  >
>>  > Aishwarya
>>
>>  Regards
>>
>>  Ozgur

Re: Documentation: rapidio: move sysfs interface to ABI

[Ozgur]

08.01.2018, 12:03, "Aishwarya Pant" :
> On Mon, Jan 08, 2018 at 11:58:12AM +0300, Ozgur wrote:
>>  08.01.2018, 11:38, "Aishwarya Pant" :
>>  > Hi
>>
>>  Hello,
>>
>>  > In Documentation/rapidio/sysfs.txt, there is a description of the sysfs
>>  > interface which could be moved to Documentation/ABI (as a bus interface 
>> under
>>  > testing).
>>  >
>>  > Would such a change be useful?
>>  >
>>  > The ABI documentation format looks like the following:
>>  >
>>  > What: (the full sysfs path of the attribute)
>>  > Date: (date of creation)
>>  > KernelVersion: (kernel version it first showed up in)
>>  > Contact: (primary contact)
>>  > Description: (long description on usage)
>>
>>  Please you make the change you want after send your patch it diff format, 
>> right?
>>  I think a better decision can be made.
>
> This is the idea. If this change is acceptable, then I can make a patch and 
> send
> it for review.

Hm,

I think firstly you should send the patch then everybody checked and change is 
decided.


Regards

Ozgur

> Aishwarya
>
>>  > I am doing this in an exercise to move sysfs ABI interfaces (which are
>>  > documented) to their right place i.e. in Documentation/ABI along with the 
>> rest.
>>  >
>>  > Aishwarya
>>
>>  Regards
>>
>>  Ozgur

Re: Documentation: rapidio: move sysfs interface to ABI

[Ozgur]

08.01.2018, 11:38, "Aishwarya Pant" <aishp...@gmail.com>:
> Hi

Hello,

> In Documentation/rapidio/sysfs.txt, there is a description of the sysfs
> interface which could be moved to Documentation/ABI (as a bus interface under
> testing).
>
> Would such a change be useful?
>
> The ABI documentation format looks like the following:
>
> What: (the full sysfs path of the attribute)
> Date: (date of creation)
> KernelVersion: (kernel version it first showed up in)
> Contact: (primary contact)
> Description: (long description on usage)

Please you make the change you want after send your patch it diff format, right?
I think a better decision can be made.

> I am doing this in an exercise to move sysfs ABI interfaces (which are
> documented) to their right place i.e. in Documentation/ABI along with the 
> rest.
>
> Aishwarya

Regards

Ozgur

Re: Documentation: rapidio: move sysfs interface to ABI

[Ozgur]

08.01.2018, 11:38, "Aishwarya Pant" :
> Hi

Hello,

> In Documentation/rapidio/sysfs.txt, there is a description of the sysfs
> interface which could be moved to Documentation/ABI (as a bus interface under
> testing).
>
> Would such a change be useful?
>
> The ABI documentation format looks like the following:
>
> What: (the full sysfs path of the attribute)
> Date: (date of creation)
> KernelVersion: (kernel version it first showed up in)
> Contact: (primary contact)
> Description: (long description on usage)

Please you make the change you want after send your patch it diff format, right?
I think a better decision can be made.

> I am doing this in an exercise to move sysfs ABI interfaces (which are
> documented) to their right place i.e. in Documentation/ABI along with the 
> rest.
>
> Aishwarya

Regards

Ozgur

Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs

[Ozgur]

07.01.2018, 15:29, "Theodore Ts'o" <ty...@mit.edu>:
> On Sun, Jan 07, 2018 at 11:16:28AM +0200, Avi Kivity wrote:
>>  I think capabilities will work just as well with cgroups. The container
>>  manager will set CAP_PAYLOAD to payload containers; and if those run an init
>>  system or a container manager themselves, they'll drop CAP_PAYLOAD for all
>>  process/sub-containers but their payloads.
>
> The reason why cgroups are better is Spectre can be used to steal
> information from within the same privilege level --- e.g., you could
> use Javascript to steal a user's Coindesk credentials or Lastpass
> data, which is going to be *way* more lucrative than trying to mine
> cryptocurrency in the sly in a user's browser. :-)

I think the web coin mining pages also work with this method they probably use 
JS in the background but currently, impossible to do kernel-level operations.
All process start on the browser level and Spectre not read kernel memory, 
right?

Ozgur

> As a result, you probably want Spectre mitigations to be enabled in a
> root process --- which means capabilities aren't the right answer.
>
> Regards,
>
> - Ted

Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs

[Ozgur]

07.01.2018, 15:29, "Theodore Ts'o" :
> On Sun, Jan 07, 2018 at 11:16:28AM +0200, Avi Kivity wrote:
>>  I think capabilities will work just as well with cgroups. The container
>>  manager will set CAP_PAYLOAD to payload containers; and if those run an init
>>  system or a container manager themselves, they'll drop CAP_PAYLOAD for all
>>  process/sub-containers but their payloads.
>
> The reason why cgroups are better is Spectre can be used to steal
> information from within the same privilege level --- e.g., you could
> use Javascript to steal a user's Coindesk credentials or Lastpass
> data, which is going to be *way* more lucrative than trying to mine
> cryptocurrency in the sly in a user's browser. :-)

I think the web coin mining pages also work with this method they probably use 
JS in the background but currently, impossible to do kernel-level operations.
All process start on the browser level and Spectre not read kernel memory, 
right?

Ozgur

> As a result, you probably want Spectre mitigations to be enabled in a
> root process --- which means capabilities aren't the right answer.
>
> Regards,
>
> - Ted

[PATCH] Documentation: Fix 00-INDEX file

[Ozgur]

Updated 00-INDEX file and added non-directories, add descriptions.

Signed-off-by: Ozgur Karatas <oz...@goosey.org>

---
 Documentation/00-INDEX | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 3bec49c33bbb..88eba10037c3 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -72,6 +72,9 @@ block/
- info on the Block I/O (BIO) layer.
 blockdev/
- info on block devices & drivers
+bpf/
+   - Q on Berkeley Packet Filter
+
 bt8xxgpio.txt
- info on how to modify a bt8xx video card for GPIO usage.
 btmrvl.txt
@@ -230,6 +233,8 @@ kbuild/
- directory with info about the kernel build process.
 kernel-doc-nano-HOWTO.txt
- outdated info about kernel-doc documentation.
+kernel-hacking/
+   - include on guide to hacking Linux kernel.
 kdump/
- directory with mini HowTo on getting the crash dump code to work.
 doc-guide/
@@ -248,6 +253,8 @@ ldm.txt
- a brief description of LDM (Windows Dynamic Disks).
 leds/
- directory with info about LED handling under Linux.
+lightnvm/
+   - info on pblk (physical block device target).
 livepatch/
- info on kernel live patching.
 locking/
@@ -314,6 +321,8 @@ nvmem/
- info on non volatile memory framework.
 output/
- default directory where html/LaTeX/pdf files will be written.
+openrisc/
+   - include on information of Linux to the OpenRISC.
 padata.txt
- An introduction to the "padata" parallel execution API
 parisc/
@@ -327,7 +336,7 @@ percpu-rw-semaphore.txt
 perf/
- info about the APM X-Gene SoC Performance Monitoring Unit (PMU).
 phy/
-   - ino on Samsung USB 2.0 PHY adaptation layer.
+   - info on Samsung USB 2.0 PHY adaptation layer.
 phy.txt
- Description of the generic PHY framework.
 pi-futex.txt
@@ -394,6 +403,8 @@ sound/
- directory with info on sound card support.
 spi/
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
+sparc/
+   - directory info on Sparc console access.
 sphinx/
- no documentation here, just files required by Sphinx toolchain.
 sphinx-static/
@@ -424,6 +435,8 @@ unshare.txt
- description of the Linux unshare system call.
 usb/
- directory with info regarding the Universal Serial Bus.
+userspace-api/
+   - directory with info Linux kernel user-space API guide.
 vfio.txt
- info on Virtual Function I/O used in guest/hypervisor instances.
 video-output.txt
-- 
2.11.0

[PATCH] Documentation: Fix 00-INDEX file

[Ozgur]

Updated 00-INDEX file and added non-directories, add descriptions.

Signed-off-by: Ozgur Karatas 

---
 Documentation/00-INDEX | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 3bec49c33bbb..88eba10037c3 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -72,6 +72,9 @@ block/
- info on the Block I/O (BIO) layer.
 blockdev/
- info on block devices & drivers
+bpf/
+   - Q on Berkeley Packet Filter
+
 bt8xxgpio.txt
- info on how to modify a bt8xx video card for GPIO usage.
 btmrvl.txt
@@ -230,6 +233,8 @@ kbuild/
- directory with info about the kernel build process.
 kernel-doc-nano-HOWTO.txt
- outdated info about kernel-doc documentation.
+kernel-hacking/
+   - include on guide to hacking Linux kernel.
 kdump/
- directory with mini HowTo on getting the crash dump code to work.
 doc-guide/
@@ -248,6 +253,8 @@ ldm.txt
- a brief description of LDM (Windows Dynamic Disks).
 leds/
- directory with info about LED handling under Linux.
+lightnvm/
+   - info on pblk (physical block device target).
 livepatch/
- info on kernel live patching.
 locking/
@@ -314,6 +321,8 @@ nvmem/
- info on non volatile memory framework.
 output/
- default directory where html/LaTeX/pdf files will be written.
+openrisc/
+   - include on information of Linux to the OpenRISC.
 padata.txt
- An introduction to the "padata" parallel execution API
 parisc/
@@ -327,7 +336,7 @@ percpu-rw-semaphore.txt
 perf/
- info about the APM X-Gene SoC Performance Monitoring Unit (PMU).
 phy/
-   - ino on Samsung USB 2.0 PHY adaptation layer.
+   - info on Samsung USB 2.0 PHY adaptation layer.
 phy.txt
- Description of the generic PHY framework.
 pi-futex.txt
@@ -394,6 +403,8 @@ sound/
- directory with info on sound card support.
 spi/
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
+sparc/
+   - directory info on Sparc console access.
 sphinx/
- no documentation here, just files required by Sphinx toolchain.
 sphinx-static/
@@ -424,6 +435,8 @@ unshare.txt
- description of the Linux unshare system call.
 usb/
- directory with info regarding the Universal Serial Bus.
+userspace-api/
+   - directory with info Linux kernel user-space API guide.
 vfio.txt
- info on Virtual Function I/O used in guest/hypervisor instances.
 video-output.txt
-- 
2.11.0

Re: LKML admins (syzbot emails are not delivered)

[Ozgur]

04.01.2018, 18:31, "David Miller" <da...@davemloft.net>:
> From: Ozgur <oz...@goosey.org>
> Date: Thu, 04 Jan 2018 12:56:56 +0300

Dvyukov,

I think you will set a bot sensitive and syzbot send e-mail that it doesn't 
disturb list members :)
David is sometimes nervous.

Ozgur

>>  autoanswer is just automated reply address that the lmkl system works and 
>> your email arrives.
>>  LKML e-mail list implemented SPF, DKIM and DMARC and I think some domains 
>> were forbid.
>>  For example yandex.ru or mail.ru
>
> If I am given specific examples of postings that don't arrive from this point 
> forward
> I can look into them.
>
> But I have to be alerted very quickly after the face rather than a day or so 
> later.
>
> I also only process vger.kernel.org bounces and postmaster email about once, 
> maybe
> twice per day. So please keep this in mind in your expectations.
>
> Thank you.

Re: LKML admins (syzbot emails are not delivered)

[Ozgur]

04.01.2018, 18:31, "David Miller" :
> From: Ozgur 
> Date: Thu, 04 Jan 2018 12:56:56 +0300

Dvyukov,

I think you will set a bot sensitive and syzbot send e-mail that it doesn't 
disturb list members :)
David is sometimes nervous.

Ozgur

>>  autoanswer is just automated reply address that the lmkl system works and 
>> your email arrives.
>>  LKML e-mail list implemented SPF, DKIM and DMARC and I think some domains 
>> were forbid.
>>  For example yandex.ru or mail.ru
>
> If I am given specific examples of postings that don't arrive from this point 
> forward
> I can look into them.
>
> But I have to be alerted very quickly after the face rather than a day or so 
> later.
>
> I also only process vger.kernel.org bounces and postmaster email about once, 
> maybe
> twice per day. So please keep this in mind in your expectations.
>
> Thank you.

Re: LKML admins (syzbot emails are not delivered)

[Ozgur]

04.01.2018, 12:23, "Greg Kroah-Hartman" <gre...@linuxfoundation.org>:
> On Thu, Jan 04, 2018 at 10:09:16AM +0100, Dmitry Vyukov wrote:
>>  Hello,
>>
>>  Some of syzbot emails don't appear on LKML mailing lists, while they
>>  were mailed as any other emails. Here are few examples:
>>
>>  "KASAN: use-after-free Read in rds_tcp_dev_event"
>>  https://groups.google.com/d/msg/syzkaller-bugs/nEeIAsNLWL4/1GzamOmRAwAJ
>>
>>  "general protection fault in __wake_up_common"
>>  https://groups.google.com/d/msg/syzkaller-bugs/4TrrZ0bIViw/rBcYLUJHAgAJ
>>
>>  Does anybody know how to get in contact with real people behind LKML
>>  and/or bugzilla?
>>
>>  I am trying to understand why this happens, but failed so far (it does
>>  not do any obviously prohibited stuff, and replies to these emails are
>>  delivered).
>
> You should get a bounce notice from vger if the email is being rejected.
> If not, you might be on the spam filter list, which is listed on vger,
> did you check that?
>
>>  I tried to use autoans...@vger.kernel.org (which is
>>  referenced from http://vger.kernel.org/majordomo-info.html), but it
>>  now always return:
>>
>>  554 5.0.0 Hi [209.85.192.182], unresolvable address:
>>  <autoans...@vger.kernel.org>; nosuchuser; autoans...@vger.kernel.org

Hello,

autoanswer is just automated reply address that the lmkl system works and your 
email arrives.
LKML e-mail list implemented SPF, DKIM and DMARC and I think some domains were 
forbid.
For example yandex.ru or mail.ru

I think should add David (Miller), I added.

> autoanswer is not for admin requests.
>
>>  I failed to find any admin email referenced anywhere.
>
> Look a bit harder, like at the bottom of this page:
> http://vger.kernel.org/majordomo-info.html
>
> :)
>
>>  On a related note, I also tried to contact bugzilla admins via
>>  rt.linuxfoundation.org. But there is complete silence. Does anybody
>>  know how to get it touch with these people?

And please check MX:

http://vger.kernel.org/mxverify.html

Ozgur

> Did you get an answer back from the rt system? If not, it did not go
> through, and the help address might have changed. I can dig it up if
> so...
>
> thanks,
>
> greg k-h

Re: LKML admins (syzbot emails are not delivered)

[Ozgur]

04.01.2018, 12:23, "Greg Kroah-Hartman" :
> On Thu, Jan 04, 2018 at 10:09:16AM +0100, Dmitry Vyukov wrote:
>>  Hello,
>>
>>  Some of syzbot emails don't appear on LKML mailing lists, while they
>>  were mailed as any other emails. Here are few examples:
>>
>>  "KASAN: use-after-free Read in rds_tcp_dev_event"
>>  https://groups.google.com/d/msg/syzkaller-bugs/nEeIAsNLWL4/1GzamOmRAwAJ
>>
>>  "general protection fault in __wake_up_common"
>>  https://groups.google.com/d/msg/syzkaller-bugs/4TrrZ0bIViw/rBcYLUJHAgAJ
>>
>>  Does anybody know how to get in contact with real people behind LKML
>>  and/or bugzilla?
>>
>>  I am trying to understand why this happens, but failed so far (it does
>>  not do any obviously prohibited stuff, and replies to these emails are
>>  delivered).
>
> You should get a bounce notice from vger if the email is being rejected.
> If not, you might be on the spam filter list, which is listed on vger,
> did you check that?
>
>>  I tried to use autoans...@vger.kernel.org (which is
>>  referenced from http://vger.kernel.org/majordomo-info.html), but it
>>  now always return:
>>
>>  554 5.0.0 Hi [209.85.192.182], unresolvable address:
>>  ; nosuchuser; autoans...@vger.kernel.org

Hello,

autoanswer is just automated reply address that the lmkl system works and your 
email arrives.
LKML e-mail list implemented SPF, DKIM and DMARC and I think some domains were 
forbid.
For example yandex.ru or mail.ru

I think should add David (Miller), I added.

> autoanswer is not for admin requests.
>
>>  I failed to find any admin email referenced anywhere.
>
> Look a bit harder, like at the bottom of this page:
> http://vger.kernel.org/majordomo-info.html
>
> :)
>
>>  On a related note, I also tried to contact bugzilla admins via
>>  rt.linuxfoundation.org. But there is complete silence. Does anybody
>>  know how to get it touch with these people?

And please check MX:

http://vger.kernel.org/mxverify.html

Ozgur

> Did you get an answer back from the rt system? If not, it did not go
> through, and the help address might have changed. I can dig it up if
> so...
>
> thanks,
>
> greg k-h

Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock

[Ozgur]

03.01.2018, 21:57, "Cong Wang" <xiyou.wangc...@gmail.com>:
> On Tue, Jan 2, 2018 at 3:58 PM, syzbot
> <syzbot+6dc95bddc6976b800...@syzkaller.appspotmail.com> wrote:
>>  Hello,
>>
>>  syzkaller hit the following crash on
>>  61233580f1f33c50e159c50e24d80ffd2ba2e06b
>>  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>>  compiler: gcc (GCC) 7.1.1 20170620
>>  .config is attached
>>  Raw console output is attached.
>>  C reproducer is attached
>>  syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>>  for information about syzkaller reproducers
>>
>>  IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>  Reported-by: syzbot+6dc95bddc6976b800...@syzkaller.appspotmail.com
>>  It will help syzbot understand when the bug is fixed. See footer for
>>  details.
>>  If you forward the report, please keep this part and the footer.
>>
>>  TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
>>  cookies. Check SNMP counters.
>>  ==
>>  BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
>>  BUG: KASAN: slab-out-of-bounds in tcp_v6_syn_recv_sock+0x628/0x23a0
>>  net/ipv6/tcp_ipv6.c:1144
>>  Write of size 160 at addr 8801cbdd7460 by task syzkaller545407/3196
>>
>>  CPU: 1 PID: 3196 Comm: syzkaller545407 Not tainted 4.15.0-rc5+ #241
>>  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>  Google 01/01/2011
>>  Call Trace:
>>   
>>   __dump_stack lib/dump_stack.c:17 [inline]
>>   dump_stack+0x194/0x257 lib/dump_stack.c:53
>>   print_address_description+0x73/0x250 mm/kasan/report.c:252
>>   kasan_report_error mm/kasan/report.c:351 [inline]
>>   kasan_report+0x25b/0x340 mm/kasan/report.c:409
>>   check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>>   check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>>   memcpy+0x37/0x50 mm/kasan/kasan.c:303
>>   memcpy include/linux/string.h:344 [inline]
>>   tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144
>
> tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads
> to this bug. I guess IPv6 is not supported for TLS? If so, need
> a check on proto in tls_init()...

Hello,

I think IPv6 supports with TLS.
There was a previously posted commit by Mellanox:

https://patchwork.ozlabs.org/patch/801530/

Ozgur

>>   tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
>>   cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
>>   tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
>>   tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
>>   tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
>>   ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
>>   NF_HOOK include/linux/netfilter.h:250 [inline]
>>   ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
>>   dst_input include/net/dst.h:466 [inline]
>>   ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
>>   NF_HOOK include/linux/netfilter.h:250 [inline]
>>   ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
>>   __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
>>   __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
>>   process_backlog+0x203/0x740 net/core/dev.c:5205
>>   napi_poll net/core/dev.c:5603 [inline]
>>   net_rx_action+0x792/0x1910 net/core/dev.c:5669
>>   __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>>   do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1115
>>   
>>   do_softirq.part.21+0x14d/0x190 kernel/softirq.c:329
>>   do_softirq kernel/softirq.c:177 [inline]
>>   __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
>>   local_bh_enable include/linux/bottom_half.h:32 [inline]
>>   rcu_read_unlock_bh include/linux/rcupdate.h:727 [inline]
>>   ip6_finish_output2+0xba6/0x2390 net/ipv6/ip6_output.c:121
>>   ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
>>   NF_HOOK_COND include/linux/netfilter.h:239 [inline]
>>   ip6_output+0x1eb/0x840 net/ipv6/ip6_output.c:163
>>   dst_output include/net/dst.h:460 [inline]
>>   NF_HOOK include/linux/netfilter.h:250 [inline]
>>   ip6_xmit+0xd75/0x2080 net/ipv6/ip6_output.c:269
>>   inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>>   tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>>   tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367
>>   __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543
>>   tcp_send_fin+0x1b0/0xd20 net/ipv4/tcp_output.c:3087
>>   tcp_close+0xbe0/0xfc0 net/ipv4/tcp.c:2234
>&g

Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock

[Ozgur]

03.01.2018, 21:57, "Cong Wang" :
> On Tue, Jan 2, 2018 at 3:58 PM, syzbot
>  wrote:
>>  Hello,
>>
>>  syzkaller hit the following crash on
>>  61233580f1f33c50e159c50e24d80ffd2ba2e06b
>>  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>>  compiler: gcc (GCC) 7.1.1 20170620
>>  .config is attached
>>  Raw console output is attached.
>>  C reproducer is attached
>>  syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>>  for information about syzkaller reproducers
>>
>>  IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>  Reported-by: syzbot+6dc95bddc6976b800...@syzkaller.appspotmail.com
>>  It will help syzbot understand when the bug is fixed. See footer for
>>  details.
>>  If you forward the report, please keep this part and the footer.
>>
>>  TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
>>  cookies. Check SNMP counters.
>>  ==
>>  BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
>>  BUG: KASAN: slab-out-of-bounds in tcp_v6_syn_recv_sock+0x628/0x23a0
>>  net/ipv6/tcp_ipv6.c:1144
>>  Write of size 160 at addr 8801cbdd7460 by task syzkaller545407/3196
>>
>>  CPU: 1 PID: 3196 Comm: syzkaller545407 Not tainted 4.15.0-rc5+ #241
>>  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>  Google 01/01/2011
>>  Call Trace:
>>   
>>   __dump_stack lib/dump_stack.c:17 [inline]
>>   dump_stack+0x194/0x257 lib/dump_stack.c:53
>>   print_address_description+0x73/0x250 mm/kasan/report.c:252
>>   kasan_report_error mm/kasan/report.c:351 [inline]
>>   kasan_report+0x25b/0x340 mm/kasan/report.c:409
>>   check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>>   check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>>   memcpy+0x37/0x50 mm/kasan/kasan.c:303
>>   memcpy include/linux/string.h:344 [inline]
>>   tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144
>
> tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads
> to this bug. I guess IPv6 is not supported for TLS? If so, need
> a check on proto in tls_init()...

Hello,

I think IPv6 supports with TLS.
There was a previously posted commit by Mellanox:

https://patchwork.ozlabs.org/patch/801530/

Ozgur

>>   tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
>>   cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
>>   tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
>>   tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
>>   tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
>>   ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
>>   NF_HOOK include/linux/netfilter.h:250 [inline]
>>   ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
>>   dst_input include/net/dst.h:466 [inline]
>>   ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
>>   NF_HOOK include/linux/netfilter.h:250 [inline]
>>   ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
>>   __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
>>   __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
>>   process_backlog+0x203/0x740 net/core/dev.c:5205
>>   napi_poll net/core/dev.c:5603 [inline]
>>   net_rx_action+0x792/0x1910 net/core/dev.c:5669
>>   __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>>   do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1115
>>   
>>   do_softirq.part.21+0x14d/0x190 kernel/softirq.c:329
>>   do_softirq kernel/softirq.c:177 [inline]
>>   __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
>>   local_bh_enable include/linux/bottom_half.h:32 [inline]
>>   rcu_read_unlock_bh include/linux/rcupdate.h:727 [inline]
>>   ip6_finish_output2+0xba6/0x2390 net/ipv6/ip6_output.c:121
>>   ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
>>   NF_HOOK_COND include/linux/netfilter.h:239 [inline]
>>   ip6_output+0x1eb/0x840 net/ipv6/ip6_output.c:163
>>   dst_output include/net/dst.h:460 [inline]
>>   NF_HOOK include/linux/netfilter.h:250 [inline]
>>   ip6_xmit+0xd75/0x2080 net/ipv6/ip6_output.c:269
>>   inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>>   tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>>   tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367
>>   __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543
>>   tcp_send_fin+0x1b0/0xd20 net/ipv4/tcp_output.c:3087
>>   tcp_close+0xbe0/0xfc0 net/ipv4/tcp.c:2234
>>   inet_release+0xed/0x1c0 net/ipv4/af_inet.c:426
>>   inet6_release+0x50/

Re: [PATCH 2/2] Staging: most: aim-sound: sound.c: removed unnecessary parentheses

[Ozgur]

29.12.2017, 02:07, "Philippe Loctaux" <loctauxphili...@gmail.com>:
> Removed unnecessary parentheses in a if statement.
>
> Signed-off-by: Philippe Loctaux <loctauxphili...@gmail.com>
> ---
>  drivers/staging/most/aim-sound/sound.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/most/aim-sound/sound.c 
> b/drivers/staging/most/aim-sound/sound.c
> index ab2b0d833..0e79a4898 100644
> --- a/drivers/staging/most/aim-sound/sound.c
> +++ b/drivers/staging/most/aim-sound/sound.c
> @@ -166,7 +166,7 @@ static struct channel *get_channel(struct most_interface 
> *iface,
>  struct channel *channel, *tmp;
>
>  list_for_each_entry_safe(channel, tmp, _list, list) {
> - if ((channel->iface == iface) && (channel->id == channel_id))
> + if (channel->iface == iface && channel->id == channel_id)
>  return channel;
>  }

Hello,

I think this patch is not good, the code will not work. Please should 
understand in && operator and () why used with C.

Ozgur

> --
> 2.15.1

Re: [PATCH 2/2] Staging: most: aim-sound: sound.c: removed unnecessary parentheses

[Ozgur]

29.12.2017, 02:07, "Philippe Loctaux" :
> Removed unnecessary parentheses in a if statement.
>
> Signed-off-by: Philippe Loctaux 
> ---
>  drivers/staging/most/aim-sound/sound.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/most/aim-sound/sound.c 
> b/drivers/staging/most/aim-sound/sound.c
> index ab2b0d833..0e79a4898 100644
> --- a/drivers/staging/most/aim-sound/sound.c
> +++ b/drivers/staging/most/aim-sound/sound.c
> @@ -166,7 +166,7 @@ static struct channel *get_channel(struct most_interface 
> *iface,
>  struct channel *channel, *tmp;
>
>  list_for_each_entry_safe(channel, tmp, _list, list) {
> - if ((channel->iface == iface) && (channel->id == channel_id))
> + if (channel->iface == iface && channel->id == channel_id)
>  return channel;
>  }

Hello,

I think this patch is not good, the code will not work. Please should 
understand in && operator and () why used with C.

Ozgur

> --
> 2.15.1

Re: [PATCH 0/2] Staging: most: aim-sound: sound.c: coding style

[Ozgur]

29.12.2017, 02:07, "Philippe Loctaux" <loctauxphili...@gmail.com>:
> Fixes checkpatch coding style issues.

Hello,

how can i see is changed/patched code lines?

Ozgur

> Philippe Loctaux (2):
>   Staging: most: aim-sound: sound.c: fixed an alignment issue
>   Staging: most: aim-sound: sound.c: removed unnecessary parentheses
>
>  drivers/staging/most/aim-sound/sound.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> --
> 2.15.1

Re: [PATCH 0/2] Staging: most: aim-sound: sound.c: coding style

[Ozgur]

29.12.2017, 02:07, "Philippe Loctaux" :
> Fixes checkpatch coding style issues.

Hello,

how can i see is changed/patched code lines?

Ozgur

> Philippe Loctaux (2):
>   Staging: most: aim-sound: sound.c: fixed an alignment issue
>   Staging: most: aim-sound: sound.c: removed unnecessary parentheses
>
>  drivers/staging/most/aim-sound/sound.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> --
> 2.15.1

Re: niced tasks on SMT system

[Ozgur]

28.12.2017, 23:59, "Pavel Machek" <pa...@ucw.cz>:
> Hi!
>
>>  >>  > Ok, so I'm compiling, and I'd like to run a flight simulator.
>>  >>  >
>>  >>  > Flightgear normally does 20fps on my system... kinda low but playable.
>>  >>  >
>>  >>  > I have reniced make -j 5 fo kernel running. Scheduler gives 100% of
>>  >>  > one of CPUs to Flightgear (good), but the smt sibling is used by the
>>  >>  > compilation, and I'm down to 9 fps. Not good.
>>  >>  >
>>  >>  > Even with single-threaded make, I have 10-13fps.
>>  >>  >
>>  >>  > Is there way to learn which CPUs are SMT siblings?
>>  >>
>>  >>  cat /sys/devices/system/cpu/cpu{N}/topology/thread_siblings
>>  >
>>  > Thanks for a hint.
>>  >
>>  > Well, something is definitely wrong there:
>>  >
>>  > pavel@duo:/data/l/linux-n900$ cat
>>  > /sys/devices/system/cpu/cpu0/topology/thread_siblings
>>  > 03
>>
>>  Ops,
>>
>>  do you fly on N900 via flightgear? :)
>>  I have two N900 and one run gentoo.
>
> No, no flightgear on N900. It was preparing kernels for my N900 that
> interfered with flying.

I would like to be involved in the team and share the job. firstly I will read 
the project documents.

> BTW there's lot of fun to be had with
> N900. https://wiki.postmarketos.org/wiki/Nokia_N900_(nokia-rx51) I
> even have voice calls working on Debian, help welcome :-).

I use default Maemo, the n900 is already debian, gentoo run a chroot :)

> Pavel

Ozgur

> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: niced tasks on SMT system

[Ozgur]

28.12.2017, 23:59, "Pavel Machek" :
> Hi!
>
>>  >>  > Ok, so I'm compiling, and I'd like to run a flight simulator.
>>  >>  >
>>  >>  > Flightgear normally does 20fps on my system... kinda low but playable.
>>  >>  >
>>  >>  > I have reniced make -j 5 fo kernel running. Scheduler gives 100% of
>>  >>  > one of CPUs to Flightgear (good), but the smt sibling is used by the
>>  >>  > compilation, and I'm down to 9 fps. Not good.
>>  >>  >
>>  >>  > Even with single-threaded make, I have 10-13fps.
>>  >>  >
>>  >>  > Is there way to learn which CPUs are SMT siblings?
>>  >>
>>  >>  cat /sys/devices/system/cpu/cpu{N}/topology/thread_siblings
>>  >
>>  > Thanks for a hint.
>>  >
>>  > Well, something is definitely wrong there:
>>  >
>>  > pavel@duo:/data/l/linux-n900$ cat
>>  > /sys/devices/system/cpu/cpu0/topology/thread_siblings
>>  > 03
>>
>>  Ops,
>>
>>  do you fly on N900 via flightgear? :)
>>  I have two N900 and one run gentoo.
>
> No, no flightgear on N900. It was preparing kernels for my N900 that
> interfered with flying.

I would like to be involved in the team and share the job. firstly I will read 
the project documents.

> BTW there's lot of fun to be had with
> N900. https://wiki.postmarketos.org/wiki/Nokia_N900_(nokia-rx51) I
> even have voice calls working on Debian, help welcome :-).

I use default Maemo, the n900 is already debian, gentoo run a chroot :)

> Pavel

Ozgur

> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: niced tasks on SMT system

[Ozgur]

28.12.2017, 21:54, "Pavel Machek" :
> Hi!
>
>>  > Ok, so I'm compiling, and I'd like to run a flight simulator.
>>  >
>>  > Flightgear normally does 20fps on my system... kinda low but playable.
>>  >
>>  > I have reniced make -j 5 fo kernel running. Scheduler gives 100% of
>>  > one of CPUs to Flightgear (good), but the smt sibling is used by the
>>  > compilation, and I'm down to 9 fps. Not good.
>>  >
>>  > Even with single-threaded make, I have 10-13fps.
>>  >
>>  > Is there way to learn which CPUs are SMT siblings?
>>
>>  cat /sys/devices/system/cpu/cpu{N}/topology/thread_siblings
>
> Thanks for a hint.
>
> Well, something is definitely wrong there:
>
> pavel@duo:/data/l/linux-n900$ cat
> /sys/devices/system/cpu/cpu0/topology/thread_siblings
> 03

Ops,

do you fly on N900 via flightgear? :)
I have two N900 and one run gentoo.

> I believe that means that cpu0 & cpu1 are sharing physical cpu. Yet,
> when I run flightgear and "nice while1". flightgear goes to CPU#0 and
> while1 to CPU#1. Would not it be nice if while1 went preferably to
> CPUs #2 and #3? Ok. after a while while1 moved to cpu#2, good.
>
>>  > Is there way to disable SMT during runtime?
>>
>>  You could offline them, but wouldn't it be better to tell each which
>>  CPUs they can use, or perhaps partition your box with cpusets?
>
> Let me try offlining first... and yes, SMT seems to be problem here.
>
> | CPU0 | CPU1 | CPU2 | CPU3 | |
> | flightgear | off | off | off | 21 fps |
> | flightgear | while1 | off | off | 17 fps |
> | flightgear+while1 | off | off | off | 10 fps |
> | flightgear | off | while1 | off | 21 fps |
>
>>  > Can I do something to improve Flightgear performance and still do
>>  > compilation?
>>
>>  Sure, run everything associated with your game as RT, and everything
>>  not game gets the leftover cycles.  If there are none, box will
>>   throttle RT to save itself from it's psycho :) driver and you'll know
>>  that you need a bigger box. (it's likely your phone)
>
>>  Oh yeah, echo NO_RT_RUNTIME_SHARE > /sys/kernel/debug/sched_features
>>  before you try that, otherwise the throttle won't help.
>
> Sure, but that is not a problem I have.
>
> Scheduler already (correctly) decides that the game is important, and
> gives game all the time it wants (100% of one CPU). That is not a problem.
>
> Problem seems to be that it schedules other tasks to SMT sibling, and
> that slows down the game quite significantly.
>
> Best regards,
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: niced tasks on SMT system

[Ozgur]

28.12.2017, 21:54, "Pavel Machek" :
> Hi!
>
>>  > Ok, so I'm compiling, and I'd like to run a flight simulator.
>>  >
>>  > Flightgear normally does 20fps on my system... kinda low but playable.
>>  >
>>  > I have reniced make -j 5 fo kernel running. Scheduler gives 100% of
>>  > one of CPUs to Flightgear (good), but the smt sibling is used by the
>>  > compilation, and I'm down to 9 fps. Not good.
>>  >
>>  > Even with single-threaded make, I have 10-13fps.
>>  >
>>  > Is there way to learn which CPUs are SMT siblings?
>>
>>  cat /sys/devices/system/cpu/cpu{N}/topology/thread_siblings
>
> Thanks for a hint.
>
> Well, something is definitely wrong there:
>
> pavel@duo:/data/l/linux-n900$ cat
> /sys/devices/system/cpu/cpu0/topology/thread_siblings
> 03

Ops,

do you fly on N900 via flightgear? :)
I have two N900 and one run gentoo.

> I believe that means that cpu0 & cpu1 are sharing physical cpu. Yet,
> when I run flightgear and "nice while1". flightgear goes to CPU#0 and
> while1 to CPU#1. Would not it be nice if while1 went preferably to
> CPUs #2 and #3? Ok. after a while while1 moved to cpu#2, good.
>
>>  > Is there way to disable SMT during runtime?
>>
>>  You could offline them, but wouldn't it be better to tell each which
>>  CPUs they can use, or perhaps partition your box with cpusets?
>
> Let me try offlining first... and yes, SMT seems to be problem here.
>
> | CPU0 | CPU1 | CPU2 | CPU3 | |
> | flightgear | off | off | off | 21 fps |
> | flightgear | while1 | off | off | 17 fps |
> | flightgear+while1 | off | off | off | 10 fps |
> | flightgear | off | while1 | off | 21 fps |
>
>>  > Can I do something to improve Flightgear performance and still do
>>  > compilation?
>>
>>  Sure, run everything associated with your game as RT, and everything
>>  not game gets the leftover cycles.  If there are none, box will
>>   throttle RT to save itself from it's psycho :) driver and you'll know
>>  that you need a bigger box. (it's likely your phone)
>
>>  Oh yeah, echo NO_RT_RUNTIME_SHARE > /sys/kernel/debug/sched_features
>>  before you try that, otherwise the throttle won't help.
>
> Sure, but that is not a problem I have.
>
> Scheduler already (correctly) decides that the game is important, and
> gives game all the time it wants (100% of one CPU). That is not a problem.
>
> Problem seems to be that it schedules other tasks to SMT sibling, and
> that slows down the game quite significantly.
>
> Best regards,
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: rtc: sysfs: move sysfs interface to Documentation/ABI

[Ozgur]

28.12.2017, 18:00, "Aishwarya Pant" <aishp...@gmail.com>:
> On Thu, Dec 28, 2017 at 05:23:33PM +0300, Ozgur wrote:
>>  28.12.2017, 17:22, "Ozgur" <okara...@yandex.com>:
>>  > 28.12.2017, 16:31, "Aishwarya Pant" <aishp...@gmail.com>:
>>  >>  Hi
>>
>>   Hello,
>>
>>  >>  In Documentation/rtc.txt, there is a description of the sysfs
>>  >>  interface which could be moved to Documentation/ABI.
>>  >>
>>  >>  Would such a change be useful?
>>  >>
>>  >>  The ABI documentation format looks like the following:
>>  >>
>>  >>  What: (the full sysfs path of the attribute)
>>  >>  Date: (date of creation)
>>  >>  KernelVersion: (kernel version it first showed up in)
>>  >>  Contact: (primary contact)
>>  >>  Description: (long description on usage)
>>  >>
>>  >>  I am doing this in an exercise to move sysfs ABI interfaces (which are
>>  >>  documented) to their right place i.e. in Documentation/ABI along with 
>> the rest.
>>
>>   Do I understand right? Are you want to make the rtc.txt part the same 
>> format as ABI folder?
>>   for example create to RTC folder and add /dev/rtc what, date, 
>> kernelversion, contact right?
>
> Yes I mentioned just the sysfs interface. But both ioctl and sysfs interface
> should be there in Documentation/ABI. There could a new file called sysfs-rtc 
> in
> Documentation/ABI/stable with both these interfaces.

Hello,

I think the ABI maintainer is API group but I think you have contact to linux 
documentation team. 
maybe, Greg provide a  give information:

>>   This can be a good idea and I can help.
>
> Sure thanks. I can maybe send a patch with these changes.
>
> One question: who should be the primary contact for this ABI?

I add linux-api mailing lists. So, please send a your patch linux-kernel and 
linux-api mailing lists.

Ozgur

>>  >>  Aishwarya
>>
>>  Ozgur

Re: rtc: sysfs: move sysfs interface to Documentation/ABI

[Ozgur]

28.12.2017, 18:00, "Aishwarya Pant" :
> On Thu, Dec 28, 2017 at 05:23:33PM +0300, Ozgur wrote:
>>  28.12.2017, 17:22, "Ozgur" :
>>  > 28.12.2017, 16:31, "Aishwarya Pant" :
>>  >>  Hi
>>
>>   Hello,
>>
>>  >>  In Documentation/rtc.txt, there is a description of the sysfs
>>  >>  interface which could be moved to Documentation/ABI.
>>  >>
>>  >>  Would such a change be useful?
>>  >>
>>  >>  The ABI documentation format looks like the following:
>>  >>
>>  >>  What: (the full sysfs path of the attribute)
>>  >>  Date: (date of creation)
>>  >>  KernelVersion: (kernel version it first showed up in)
>>  >>  Contact: (primary contact)
>>  >>  Description: (long description on usage)
>>  >>
>>  >>  I am doing this in an exercise to move sysfs ABI interfaces (which are
>>  >>  documented) to their right place i.e. in Documentation/ABI along with 
>> the rest.
>>
>>   Do I understand right? Are you want to make the rtc.txt part the same 
>> format as ABI folder?
>>   for example create to RTC folder and add /dev/rtc what, date, 
>> kernelversion, contact right?
>
> Yes I mentioned just the sysfs interface. But both ioctl and sysfs interface
> should be there in Documentation/ABI. There could a new file called sysfs-rtc 
> in
> Documentation/ABI/stable with both these interfaces.

Hello,

I think the ABI maintainer is API group but I think you have contact to linux 
documentation team. 
maybe, Greg provide a  give information:

>>   This can be a good idea and I can help.
>
> Sure thanks. I can maybe send a patch with these changes.
>
> One question: who should be the primary contact for this ABI?

I add linux-api mailing lists. So, please send a your patch linux-kernel and 
linux-api mailing lists.

Ozgur

>>  >>  Aishwarya
>>
>>  Ozgur

Re: rtc: sysfs: move sysfs interface to Documentation/ABI

[Ozgur]

28.12.2017, 17:22, "Ozgur" <okara...@yandex.com>:
> 28.12.2017, 16:31, "Aishwarya Pant" <aishp...@gmail.com>:
>>  Hi

 Hello,

>>  In Documentation/rtc.txt, there is a description of the sysfs
>>  interface which could be moved to Documentation/ABI.
>>
>>  Would such a change be useful?
>>
>>  The ABI documentation format looks like the following:
>>
>>  What: (the full sysfs path of the attribute)
>>  Date: (date of creation)
>>  KernelVersion: (kernel version it first showed up in)
>>  Contact: (primary contact)
>>  Description: (long description on usage)
>>
>>  I am doing this in an exercise to move sysfs ABI interfaces (which are
>>  documented) to their right place i.e. in Documentation/ABI along with the 
>> rest.

 Do I understand right? Are you want to make the rtc.txt part the same format 
as ABI folder?
 for example create to RTC folder and add /dev/rtc what, date, kernelversion, 
contact right?

 This can be a good idea and I can help.

>>  Aishwarya

Ozgur

Re: rtc: sysfs: move sysfs interface to Documentation/ABI

[Ozgur]

28.12.2017, 17:22, "Ozgur" :
> 28.12.2017, 16:31, "Aishwarya Pant" :
>>  Hi

 Hello,

>>  In Documentation/rtc.txt, there is a description of the sysfs
>>  interface which could be moved to Documentation/ABI.
>>
>>  Would such a change be useful?
>>
>>  The ABI documentation format looks like the following:
>>
>>  What: (the full sysfs path of the attribute)
>>  Date: (date of creation)
>>  KernelVersion: (kernel version it first showed up in)
>>  Contact: (primary contact)
>>  Description: (long description on usage)
>>
>>  I am doing this in an exercise to move sysfs ABI interfaces (which are
>>  documented) to their right place i.e. in Documentation/ABI along with the 
>> rest.

 Do I understand right? Are you want to make the rtc.txt part the same format 
as ABI folder?
 for example create to RTC folder and add /dev/rtc what, date, kernelversion, 
contact right?

 This can be a good idea and I can help.

>>  Aishwarya

Ozgur

Re: [RFC] syzbot process

[Ozgur]

28.12.2017, 15:30, "Dmitry Vyukov" <dvyu...@google.com>:
> On Thu, Dec 28, 2017 at 1:26 PM, Ozgur <oz...@goosey.org> wrote:
>
>>>>   and I think syzbot use to .txt file attached.
>>>>   .txt is not good.
>>>
>>>  Why are not .txt attachments good? What do you propose to use?
>>
>>  I think I'm misunderstood that is good to have text output in a file but 
>> not useful if the file extension is ".txt"
>>  Not comfortable use it for mutt / vim and diff.
>>
>>  I think needs to be an new extension, would be like this ".log" or ".syz" :)
>
> There is an fortunate limitation in the mailing system we currently
> use -- it infers Content-Type from file extension. So if we do .syz,
> it will do application/octet-stream.

Hello Dmitry,

I understand and thanks for detailed info, like it!

Ozgur

Re: [RFC] syzbot process

[Ozgur]

28.12.2017, 15:30, "Dmitry Vyukov" :
> On Thu, Dec 28, 2017 at 1:26 PM, Ozgur  wrote:
>
>>>>   and I think syzbot use to .txt file attached.
>>>>   .txt is not good.
>>>
>>>  Why are not .txt attachments good? What do you propose to use?
>>
>>  I think I'm misunderstood that is good to have text output in a file but 
>> not useful if the file extension is ".txt"
>>  Not comfortable use it for mutt / vim and diff.
>>
>>  I think needs to be an new extension, would be like this ".log" or ".syz" :)
>
> There is an fortunate limitation in the mailing system we currently
> use -- it infers Content-Type from file extension. So if we do .syz,
> it will do application/octet-stream.

Hello Dmitry,

I understand and thanks for detailed info, like it!

Ozgur

Re: [RFC] syzbot process

[Ozgur]

28.12.2017, 14:45, "Dmitry Vyukov" <dvyu...@google.com>:
> On Thu, Dec 28, 2017 at 11:51 AM, Ozgur <oz...@goosey.org> wrote:
>>  28.12.2017, 13:41, "Dmitry Vyukov" <dvyu...@google.com>:
>>>  On Fri, Dec 22, 2017 at 4:32 AM, Eric Biggers <ebigge...@gmail.com> wrote:
>>>>   On Thu, Dec 21, 2017 at 01:52:40PM +0100, Dmitry Vyukov wrote:
>>>>>   However, the cost is that it needs to understand statuses of bugs:
>>>>>   most importantly, what commit fixes what bug. It also has support for
>>>>>   marking a bug as "invalid", e.g. happened once but most likely was
>>>>>   caused by a previous silent memory corruption. And support for marking
>>>>>   bugs as duplicates of other bugs, i.e. the same root cause and will be
>>>>>   fixed when the target bug is fixed. These simple rules are outlined in
>>>>>   the footer of each report and also explained in more detail at the
>>>>>   referenced link:
>>>>>
>>>>>   --
>>>>>   This bug is generated by a dumb bot. It may contain errors.
>>>>>   See https://goo.gl/tpsmEJ for details.
>>>>>   Direct all questions to syzkal...@googlegroups.com.
>>>>>   Please credit me with: Reported-by: syzbot <syzkal...@googlegroups.com>
>>>>>   syzbot will keep track of this bug report.
>>>>>   Once a fix for this bug is merged into any tree, reply to this email 
>>>>> with:
>>>>>   #syz fix: exact-commit-title
>>>>>   If you want to test a patch for this bug, please reply with:
>>>>>   #syz test: git://repo/address.git branch
>>>>>   and provide the patch inline or as an attachment.
>>>>>   To mark this as a duplicate of another syzbot report, please reply with:
>>>>>   #syz dup: exact-subject-of-another-report
>>>>>   If it's a one-off invalid bug report, please reply with:
>>>>>   #syz invalid
>>>>>   Note: if the crash happens again, it will cause creation of a new bug 
>>>>> report.
>>>>>   Note: all commands must start from beginning of the line in the email 
>>>>> body.
>>>>>   --
>>>>>
>>>>>   Status tracking allows syzbot to (1) keep track of still unfixed bugs
>>>>>   (more than half actually gets lost in LKML archives if nobody keeps
>>>>>   track of them), (2) be able to ever report similarly looking crashes
>>>>>   as new bugs in future, (3) be able to test fixes.
>>>>>
>>>>>   The problem is that these rules are mostly not followed.
>>>>
>>>>   As others mentioned, allowing a bug ID to be in the fix's commit message,
>>>>   perhaps in the Reported-by line which syzbot already suggests to 
>>>> include, would
>>>>   make things a bit easier.
>>>>
>>>>   But I think the larger problem is that people in the community don't 
>>>> have any
>>>>   visibility into the statuses of the bugs, so they don't have any 
>>>> motivation to
>>>>   manage the statuses.
>>>>
>>>>   Are you planning to make a dashboard app publicly available for upstream 
>>>> kernel
>>>>   bugs being tracked by syzbot? I think it would be very useful for the
>>>>   community, especially for finding more details about a bug, e.g. when 
>>>> was it
>>>>   last seen, how often was it seen, has it been seen in multiple trees. 
>>>> Also for
>>>>   finding duplicates which may not have been sent to the correct mailing 
>>>> list.
>>>
>>>  Hi Eric,
>>>
>>>  Good question. I would very much like to open the UI, and I hope to do
>>>  it in near future, but we need to do some additional work to make it
>>>  possible. The good news is that information is already accumulating
>>>  and we can do pings, etc.
>>
>>  Hello Dmitry,
>>
>>  I think not useful to be a GUI, for example it can be console based ui we 
>> can conenct and get information and fixed patches.
>
> Hi Ozgur,

Hello,

> We will do web UI first as it's something that's already partially
> there and syzbot itself is not a console process, it's a cloud
> service. It's also handy because there are lots of contextual
> information and in a web UI one can just just click links to navigate
> or downl

Re: [RFC] syzbot process

[Ozgur]

28.12.2017, 14:45, "Dmitry Vyukov" :
> On Thu, Dec 28, 2017 at 11:51 AM, Ozgur  wrote:
>>  28.12.2017, 13:41, "Dmitry Vyukov" :
>>>  On Fri, Dec 22, 2017 at 4:32 AM, Eric Biggers  wrote:
>>>>   On Thu, Dec 21, 2017 at 01:52:40PM +0100, Dmitry Vyukov wrote:
>>>>>   However, the cost is that it needs to understand statuses of bugs:
>>>>>   most importantly, what commit fixes what bug. It also has support for
>>>>>   marking a bug as "invalid", e.g. happened once but most likely was
>>>>>   caused by a previous silent memory corruption. And support for marking
>>>>>   bugs as duplicates of other bugs, i.e. the same root cause and will be
>>>>>   fixed when the target bug is fixed. These simple rules are outlined in
>>>>>   the footer of each report and also explained in more detail at the
>>>>>   referenced link:
>>>>>
>>>>>   --
>>>>>   This bug is generated by a dumb bot. It may contain errors.
>>>>>   See https://goo.gl/tpsmEJ for details.
>>>>>   Direct all questions to syzkal...@googlegroups.com.
>>>>>   Please credit me with: Reported-by: syzbot 
>>>>>   syzbot will keep track of this bug report.
>>>>>   Once a fix for this bug is merged into any tree, reply to this email 
>>>>> with:
>>>>>   #syz fix: exact-commit-title
>>>>>   If you want to test a patch for this bug, please reply with:
>>>>>   #syz test: git://repo/address.git branch
>>>>>   and provide the patch inline or as an attachment.
>>>>>   To mark this as a duplicate of another syzbot report, please reply with:
>>>>>   #syz dup: exact-subject-of-another-report
>>>>>   If it's a one-off invalid bug report, please reply with:
>>>>>   #syz invalid
>>>>>   Note: if the crash happens again, it will cause creation of a new bug 
>>>>> report.
>>>>>   Note: all commands must start from beginning of the line in the email 
>>>>> body.
>>>>>   --
>>>>>
>>>>>   Status tracking allows syzbot to (1) keep track of still unfixed bugs
>>>>>   (more than half actually gets lost in LKML archives if nobody keeps
>>>>>   track of them), (2) be able to ever report similarly looking crashes
>>>>>   as new bugs in future, (3) be able to test fixes.
>>>>>
>>>>>   The problem is that these rules are mostly not followed.
>>>>
>>>>   As others mentioned, allowing a bug ID to be in the fix's commit message,
>>>>   perhaps in the Reported-by line which syzbot already suggests to 
>>>> include, would
>>>>   make things a bit easier.
>>>>
>>>>   But I think the larger problem is that people in the community don't 
>>>> have any
>>>>   visibility into the statuses of the bugs, so they don't have any 
>>>> motivation to
>>>>   manage the statuses.
>>>>
>>>>   Are you planning to make a dashboard app publicly available for upstream 
>>>> kernel
>>>>   bugs being tracked by syzbot? I think it would be very useful for the
>>>>   community, especially for finding more details about a bug, e.g. when 
>>>> was it
>>>>   last seen, how often was it seen, has it been seen in multiple trees. 
>>>> Also for
>>>>   finding duplicates which may not have been sent to the correct mailing 
>>>> list.
>>>
>>>  Hi Eric,
>>>
>>>  Good question. I would very much like to open the UI, and I hope to do
>>>  it in near future, but we need to do some additional work to make it
>>>  possible. The good news is that information is already accumulating
>>>  and we can do pings, etc.
>>
>>  Hello Dmitry,
>>
>>  I think not useful to be a GUI, for example it can be console based ui we 
>> can conenct and get information and fixed patches.
>
> Hi Ozgur,

Hello,

> We will do web UI first as it's something that's already partially
> there and syzbot itself is not a console process, it's a cloud
> service. It's also handy because there are lots of contextual
> information and in a web UI one can just just click links to navigate
> or download a blob. Later we could do an API for console clients, etc
> if there is an interest in developing these types of UIs. But
> generall

Re: [RFC] syzbot process

[Ozgur]

28.12.2017, 13:41, "Dmitry Vyukov" <dvyu...@google.com>:
> On Fri, Dec 22, 2017 at 4:32 AM, Eric Biggers <ebigge...@gmail.com> wrote:
>>  On Thu, Dec 21, 2017 at 01:52:40PM +0100, Dmitry Vyukov wrote:
>>>  However, the cost is that it needs to understand statuses of bugs:
>>>  most importantly, what commit fixes what bug. It also has support for
>>>  marking a bug as "invalid", e.g. happened once but most likely was
>>>  caused by a previous silent memory corruption. And support for marking
>>>  bugs as duplicates of other bugs, i.e. the same root cause and will be
>>>  fixed when the target bug is fixed. These simple rules are outlined in
>>>  the footer of each report and also explained in more detail at the
>>>  referenced link:
>>>
>>>  --
>>>  This bug is generated by a dumb bot. It may contain errors.
>>>  See https://goo.gl/tpsmEJ for details.
>>>  Direct all questions to syzkal...@googlegroups.com.
>>>  Please credit me with: Reported-by: syzbot <syzkal...@googlegroups.com>
>>>  syzbot will keep track of this bug report.
>>>  Once a fix for this bug is merged into any tree, reply to this email with:
>>>  #syz fix: exact-commit-title
>>>  If you want to test a patch for this bug, please reply with:
>>>  #syz test: git://repo/address.git branch
>>>  and provide the patch inline or as an attachment.
>>>  To mark this as a duplicate of another syzbot report, please reply with:
>>>  #syz dup: exact-subject-of-another-report
>>>  If it's a one-off invalid bug report, please reply with:
>>>  #syz invalid
>>>  Note: if the crash happens again, it will cause creation of a new bug 
>>> report.
>>>  Note: all commands must start from beginning of the line in the email body.
>>>  --
>>>
>>>  Status tracking allows syzbot to (1) keep track of still unfixed bugs
>>>  (more than half actually gets lost in LKML archives if nobody keeps
>>>  track of them), (2) be able to ever report similarly looking crashes
>>>  as new bugs in future, (3) be able to test fixes.
>>>
>>>  The problem is that these rules are mostly not followed.
>>
>>  As others mentioned, allowing a bug ID to be in the fix's commit message,
>>  perhaps in the Reported-by line which syzbot already suggests to include, 
>> would
>>  make things a bit easier.
>>
>>  But I think the larger problem is that people in the community don't have 
>> any
>>  visibility into the statuses of the bugs, so they don't have any motivation 
>> to
>>  manage the statuses.
>>
>>  Are you planning to make a dashboard app publicly available for upstream 
>> kernel
>>  bugs being tracked by syzbot? I think it would be very useful for the
>>  community, especially for finding more details about a bug, e.g. when was it
>>  last seen, how often was it seen, has it been seen in multiple trees. Also 
>> for
>>  finding duplicates which may not have been sent to the correct mailing list.
>
> Hi Eric,
>
> Good question. I would very much like to open the UI, and I hope to do
> it in near future, but we need to do some additional work to make it
> possible. The good news is that information is already accumulating
> and we can do pings, etc.

Hello Dmitry,

I think not useful to be a GUI, for example it can be console based ui we can 
conenct and get information and fixed patches.
So syzbot is perfectly, I founded a patc last time :)

https://09738734946362323617.googlegroups.com/attach/3c6ef7059f77c/patch.txt?part=0.2=1=ANaJVrFm49WFVkkKiomlnsrdfnv4P-0znjiC4agFB72ibq9_6iqg1rmZtw9-DxS5VvoOoKx8Ikl88sYEQQ45X0vjrwFkKDRaZELV-oU9DVmmrRAMSfStn24

And, I have a my suggestions:

Please keep to short url addresses and I think syzbot use to .txt file attached.
.txt is not good.

Ozgur

>>  syzbot also should be sending out reminders for bugs that are still open if 
>> the
>>  crash is still occurring, and even moreso if there is a reproducer.
>
> Agree. The reasons why this hasn't happen yet are:
> 1. syzbot is being built up as it's running, I am overwhelmed with
> hundreds of bugs and also doing lots of work which may be not directly
> visible but important (e.g. improving quality of generated
> reproducers, increasing percent of cases when reproducers are created,
> improving bug title extraction logic, implementing patch testing by
> request, now this new Reported-by-based process, etc).
> 2. Just sending an email for each open bug every week is simple, but I
> afraid it won

Re: [RFC] syzbot process

[Ozgur]

28.12.2017, 13:41, "Dmitry Vyukov" :
> On Fri, Dec 22, 2017 at 4:32 AM, Eric Biggers  wrote:
>>  On Thu, Dec 21, 2017 at 01:52:40PM +0100, Dmitry Vyukov wrote:
>>>  However, the cost is that it needs to understand statuses of bugs:
>>>  most importantly, what commit fixes what bug. It also has support for
>>>  marking a bug as "invalid", e.g. happened once but most likely was
>>>  caused by a previous silent memory corruption. And support for marking
>>>  bugs as duplicates of other bugs, i.e. the same root cause and will be
>>>  fixed when the target bug is fixed. These simple rules are outlined in
>>>  the footer of each report and also explained in more detail at the
>>>  referenced link:
>>>
>>>  --
>>>  This bug is generated by a dumb bot. It may contain errors.
>>>  See https://goo.gl/tpsmEJ for details.
>>>  Direct all questions to syzkal...@googlegroups.com.
>>>  Please credit me with: Reported-by: syzbot 
>>>  syzbot will keep track of this bug report.
>>>  Once a fix for this bug is merged into any tree, reply to this email with:
>>>  #syz fix: exact-commit-title
>>>  If you want to test a patch for this bug, please reply with:
>>>  #syz test: git://repo/address.git branch
>>>  and provide the patch inline or as an attachment.
>>>  To mark this as a duplicate of another syzbot report, please reply with:
>>>  #syz dup: exact-subject-of-another-report
>>>  If it's a one-off invalid bug report, please reply with:
>>>  #syz invalid
>>>  Note: if the crash happens again, it will cause creation of a new bug 
>>> report.
>>>  Note: all commands must start from beginning of the line in the email body.
>>>  --
>>>
>>>  Status tracking allows syzbot to (1) keep track of still unfixed bugs
>>>  (more than half actually gets lost in LKML archives if nobody keeps
>>>  track of them), (2) be able to ever report similarly looking crashes
>>>  as new bugs in future, (3) be able to test fixes.
>>>
>>>  The problem is that these rules are mostly not followed.
>>
>>  As others mentioned, allowing a bug ID to be in the fix's commit message,
>>  perhaps in the Reported-by line which syzbot already suggests to include, 
>> would
>>  make things a bit easier.
>>
>>  But I think the larger problem is that people in the community don't have 
>> any
>>  visibility into the statuses of the bugs, so they don't have any motivation 
>> to
>>  manage the statuses.
>>
>>  Are you planning to make a dashboard app publicly available for upstream 
>> kernel
>>  bugs being tracked by syzbot? I think it would be very useful for the
>>  community, especially for finding more details about a bug, e.g. when was it
>>  last seen, how often was it seen, has it been seen in multiple trees. Also 
>> for
>>  finding duplicates which may not have been sent to the correct mailing list.
>
> Hi Eric,
>
> Good question. I would very much like to open the UI, and I hope to do
> it in near future, but we need to do some additional work to make it
> possible. The good news is that information is already accumulating
> and we can do pings, etc.

Hello Dmitry,

I think not useful to be a GUI, for example it can be console based ui we can 
conenct and get information and fixed patches.
So syzbot is perfectly, I founded a patc last time :)

https://09738734946362323617.googlegroups.com/attach/3c6ef7059f77c/patch.txt?part=0.2=1=ANaJVrFm49WFVkkKiomlnsrdfnv4P-0znjiC4agFB72ibq9_6iqg1rmZtw9-DxS5VvoOoKx8Ikl88sYEQQ45X0vjrwFkKDRaZELV-oU9DVmmrRAMSfStn24

And, I have a my suggestions:

Please keep to short url addresses and I think syzbot use to .txt file attached.
.txt is not good.

Ozgur

>>  syzbot also should be sending out reminders for bugs that are still open if 
>> the
>>  crash is still occurring, and even moreso if there is a reproducer.
>
> Agree. The reasons why this hasn't happen yet are:
> 1. syzbot is being built up as it's running, I am overwhelmed with
> hundreds of bugs and also doing lots of work which may be not directly
> visible but important (e.g. improving quality of generated
> reproducers, increasing percent of cases when reproducers are created,
> improving bug title extraction logic, implementing patch testing by
> request, now this new Reported-by-based process, etc).
> 2. Just sending an email for each open bug every week is simple, but I
> afraid it won't be warmly welcomed. The open questions are: how
> frequently syzbot should ping? should rep

Re: 4.14.9 boot error (regression), 4.14.8 is fine

[Ozgur]

27.12.2017, 00:52, "Randy Dunlap" <rdun...@infradead.org>:
> On 12/26/2017 12:52 PM, Toralf Förster wrote:
>>  at a headless server: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz, stable 
>> hardened Gentoo Linux
>>  The hang does occur before any log message is written.
>>  A ping command shows, that the server does reboot and dies after 20 pings 
>> are received.
>>  The .config is attached

Hello,

Your .config file requires "yes" for most parameters.
Do you just run the "make" command by default config working copy /boot 
directory?

$ copy /boot/config* .config
$ make

Have you try this default .config? Everything is good?

>>  FWIW I'm surprised a little bit about having a new kernel option in a LTS 
>> release.
>
> It's just a renamed kernel config option, right?
> and a different default setting (UNWINDER_ORC became the new default).
>
> --
> ~Randy

Ozgur

Re: 4.14.9 boot error (regression), 4.14.8 is fine

[Ozgur]

27.12.2017, 00:52, "Randy Dunlap" :
> On 12/26/2017 12:52 PM, Toralf Förster wrote:
>>  at a headless server: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz, stable 
>> hardened Gentoo Linux
>>  The hang does occur before any log message is written.
>>  A ping command shows, that the server does reboot and dies after 20 pings 
>> are received.
>>  The .config is attached

Hello,

Your .config file requires "yes" for most parameters.
Do you just run the "make" command by default config working copy /boot 
directory?

$ copy /boot/config* .config
$ make

Have you try this default .config? Everything is good?

>>  FWIW I'm surprised a little bit about having a new kernel option in a LTS 
>> release.
>
> It's just a renamed kernel config option, right?
> and a different default setting (UNWINDER_ORC became the new default).
>
> --
> ~Randy

Ozgur

Re: 4.14.9 boot error (regression), 4.14.8 is fine

[Ozgur]

26.12.2017, 23:52, "Toralf Förster" <toralf.foers...@gmx.de>:
> at a headless server: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz, stable 
> hardened Gentoo Linux
> The hang does occur before any log message is written.
> A ping command shows, that the server does reboot and dies after 20 pings are 
> received.
> The .config is attached

Hello,
please could you little more detail of the have received errors?
You compile the kernel right? So, system is boot but not the network respond?

Regards

> FWIW I'm surprised a little bit about having a new kernel option in a LTS 
> release.
>
> --
> Toralf
> PGP C4EACDDE 0076E94E

Ozgur

Re: 4.14.9 boot error (regression), 4.14.8 is fine

[Ozgur]

26.12.2017, 23:52, "Toralf Förster" :
> at a headless server: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz, stable 
> hardened Gentoo Linux
> The hang does occur before any log message is written.
> A ping command shows, that the server does reboot and dies after 20 pings are 
> received.
> The .config is attached

Hello,
please could you little more detail of the have received errors?
You compile the kernel right? So, system is boot but not the network respond?

Regards

> FWIW I'm surprised a little bit about having a new kernel option in a LTS 
> release.
>
> --
> Toralf
> PGP C4EACDDE 0076E94E

Ozgur

Re: [PATCH] Staging: omap4iss: fix coding style issues

[Ozgur Karatas]

28.01.2017, 20:11, "Avraham Shukron" <avraham.shuk...@gmail.com>:
> This is a patch that fixes issues in omap4iss/iss_video.c
> Specifically, it fixes "line over 80 characters" issues

Hello,

are you have a sent this changes patch before?
And Greg KH answered you, are you read?

Please send the change once, there is no need for a repeat. 

> Signed-off-by: Avraham Shukron <avraham.shuk...@gmail.com>
>
> ---
>  drivers/staging/media/omap4iss/iss_video.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/omap4iss/iss_video.c 
> b/drivers/staging/media/omap4iss/iss_video.c
> index c16927a..cdab053 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -298,7 +298,8 @@ iss_video_check_format(struct iss_video *video, struct 
> iss_video_fh *vfh)
>
>  static int iss_video_queue_setup(struct vb2_queue *vq,
>   unsigned int *count, unsigned int 
> *num_planes,
> - unsigned int sizes[], struct device *alloc_devs[])
> + unsigned int sizes[],
> + struct device *alloc_devs[])

it should be on the same line, maintainer's up to 80 characters allowed.
this "alloc_devs" variable start with int?

Example:

struct device {
  int (struct device *alloc_devs[);

Check the top lines of the codes.


>  {
>  struct iss_video_fh *vfh = vb2_get_drv_priv(vq);
>  struct iss_video *video = vfh->video;
> @@ -678,8 +679,8 @@ iss_video_get_selection(struct file *file, void *fh, 
> struct v4l2_selection *sel)
>  if (subdev == NULL)
>  return -EINVAL;
>
> - /* Try the get selection operation first and fallback to get format if not
> - * implemented.
> + /* Try the get selection operation first and fallback to get format if
> + * not implemented.
>   */

There is no change here, it opens with comment /* and closes with */.
Please read submittting patch document.

Regards,

>  sdsel.pad = pad;
>  ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
> --
> 2.7.4

~Ozgur

Re: [PATCH] Staging: omap4iss: fix coding style issues

[Ozgur Karatas]

28.01.2017, 20:11, "Avraham Shukron" :
> This is a patch that fixes issues in omap4iss/iss_video.c
> Specifically, it fixes "line over 80 characters" issues

Hello,

are you have a sent this changes patch before?
And Greg KH answered you, are you read?

Please send the change once, there is no need for a repeat. 

> Signed-off-by: Avraham Shukron 
>
> ---
>  drivers/staging/media/omap4iss/iss_video.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/omap4iss/iss_video.c 
> b/drivers/staging/media/omap4iss/iss_video.c
> index c16927a..cdab053 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -298,7 +298,8 @@ iss_video_check_format(struct iss_video *video, struct 
> iss_video_fh *vfh)
>
>  static int iss_video_queue_setup(struct vb2_queue *vq,
>   unsigned int *count, unsigned int 
> *num_planes,
> - unsigned int sizes[], struct device *alloc_devs[])
> + unsigned int sizes[],
> + struct device *alloc_devs[])

it should be on the same line, maintainer's up to 80 characters allowed.
this "alloc_devs" variable start with int?

Example:

struct device {
  int (struct device *alloc_devs[);

Check the top lines of the codes.


>  {
>  struct iss_video_fh *vfh = vb2_get_drv_priv(vq);
>  struct iss_video *video = vfh->video;
> @@ -678,8 +679,8 @@ iss_video_get_selection(struct file *file, void *fh, 
> struct v4l2_selection *sel)
>  if (subdev == NULL)
>  return -EINVAL;
>
> - /* Try the get selection operation first and fallback to get format if not
> - * implemented.
> + /* Try the get selection operation first and fallback to get format if
> + * not implemented.
>   */

There is no change here, it opens with comment /* and closes with */.
Please read submittting patch document.

Regards,

>  sdsel.pad = pad;
>  ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
> --
> 2.7.4

~Ozgur

Re: lkml.org issues

[Ozgur Karatas]

26.12.2016, 10:46, "Nikita Yushchenko" <nikita.yo...@cogentembedded.com>:
> Hi
>
> Is lkml.org supported?
>
> Currently:
>
> - [headers] link on top of pages does not show message headers,

You can just display the header's list.

> - [forward] link on top of pages is not functional - it requests text
> from captcha but does not show image.

where is to forward? All?

> [forward] could be useful to get a list mail that one did not receive,
> to be able to reply to it without doing manual black magic with
> searching for message-id and forging in-reply-to headers.

previously lkml hve to FAQ please contact to tux.org

Regards,

Ozgur

Re: lkml.org issues

[Ozgur Karatas]

26.12.2016, 10:46, "Nikita Yushchenko" :
> Hi
>
> Is lkml.org supported?
>
> Currently:
>
> - [headers] link on top of pages does not show message headers,

You can just display the header's list.

> - [forward] link on top of pages is not functional - it requests text
> from captcha but does not show image.

where is to forward? All?

> [forward] could be useful to get a list mail that one did not receive,
> to be able to reply to it without doing manual black magic with
> searching for message-id and forging in-reply-to headers.

previously lkml hve to FAQ please contact to tux.org

Regards,

Ozgur

Re: Question regarding power button of Dell XPS13

[Ozgur Karatas]

26.12.2016, 00:27, "Linus Torvalds" <torva...@linux-foundation.org>:
> On Fri, Dec 23, 2016 at 4:36 AM, Paul Menzel <pmen...@molgen.mpg.de> wrote:
>>  I heard that you both have a Dell XPS13. I got the “revision” 9360, and
>>  installed Debian Stretch/testing on it with Linux 4.8.15 and Linux 4.9-rc8.
>>
>>  When pressing the power button the GNOME dialog, asking what to do (restart,
>>  power off, …) doesn’t appear.

Hello,

I don't think it's problem about to kernel. The problem related to GNOME .
I used last time and I modified the file "gsd-media-keys-manager.c" file and 
added the following lines to logind.conf file:

HandlePowerKey=poweroff
PowerKeyIgnoreInhibited=yes

This is a out of topic and XPS13 is not good, You also don't use a desktop,
Suggest Openbox :)

> Hmm. I don't recall ever seeing such a dialog. But I don't run Debian.
>
> For me it works like all power buttons on my laptops have worked
> lately - it suspends the machine.
>
> Of course, so does just closing the lid.
>
> The only "bug" I've seen in this area is the design bug of the XPS13
> where there is no visible indication of the suspend state (ie the
> traditional slowly pulsing LED showing that it's all nice and
> suspended). But that seems to be intentional, if stupid. I think it's
> the only real beef I have with the XPS13.
>
>    Linus

Regards,

Ozgur

Re: Question regarding power button of Dell XPS13

[Ozgur Karatas]

26.12.2016, 00:27, "Linus Torvalds" :
> On Fri, Dec 23, 2016 at 4:36 AM, Paul Menzel  wrote:
>>  I heard that you both have a Dell XPS13. I got the “revision” 9360, and
>>  installed Debian Stretch/testing on it with Linux 4.8.15 and Linux 4.9-rc8.
>>
>>  When pressing the power button the GNOME dialog, asking what to do (restart,
>>  power off, …) doesn’t appear.

Hello,

I don't think it's problem about to kernel. The problem related to GNOME .
I used last time and I modified the file "gsd-media-keys-manager.c" file and 
added the following lines to logind.conf file:

HandlePowerKey=poweroff
PowerKeyIgnoreInhibited=yes

This is a out of topic and XPS13 is not good, You also don't use a desktop,
Suggest Openbox :)

> Hmm. I don't recall ever seeing such a dialog. But I don't run Debian.
>
> For me it works like all power buttons on my laptops have worked
> lately - it suspends the machine.
>
> Of course, so does just closing the lid.
>
> The only "bug" I've seen in this area is the design bug of the XPS13
> where there is no visible indication of the suspend state (ie the
> traditional slowly pulsing LED showing that it's all nice and
> suspended). But that seems to be intentional, if stupid. I think it's
> the only real beef I have with the XPS13.
>
>    Linus

Regards,

Ozgur

Re: [PATCH 2/2] net: wireless: fix to uses struct

[Ozgur Karatas]

22.12.2016, 01:06, "Paul Bolle" <pebo...@tiscali.nl>:
> On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote:
>>  I don't have a problem with C programming
>
> I'm sorry, but you do need to learn C, at a basic level, first.

Hmm, I don't like to discussion but I'm an assertive on C/C++.
So, I'm not into the Linux kernel, I writing code with C/C++ for many years. 
I'm having trouble using Linux tools and trying to learn 
git/diff/format-patch/etc. 

Also, I'm reading over 600 e-mails per day and I'm reading to Documentation 
(kernel). I learn :)

I don't have to problem with C, you can see my early codes and software 
(github).

I need to get a good sense of the coding style and Documentation.

And thank you.

Regards

> Paul Bolle

~Ozgur

Re: [PATCH 2/2] net: wireless: fix to uses struct

[Ozgur Karatas]

22.12.2016, 01:06, "Paul Bolle" :
> On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote:
>>  I don't have a problem with C programming
>
> I'm sorry, but you do need to learn C, at a basic level, first.

Hmm, I don't like to discussion but I'm an assertive on C/C++.
So, I'm not into the Linux kernel, I writing code with C/C++ for many years. 
I'm having trouble using Linux tools and trying to learn 
git/diff/format-patch/etc. 

Also, I'm reading over 600 e-mails per day and I'm reading to Documentation 
(kernel). I learn :)

I don't have to problem with C, you can see my early codes and software 
(github).

I need to get a good sense of the coding style and Documentation.

And thank you.

Regards

> Paul Bolle

~Ozgur

Re: [PATCH 2/2] net: wireless: fix to uses struct

[Ozgur Karatas]

My previous patch is invalid, I'm sorry.
The last patc will be fellow because "regulatory_request" is defined as a 
"static struct".

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 net/wireless/reg.c  | 10 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
 
-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;

@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
 
-   reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+   reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
 
-- 
2.1.4

Re: [PATCH 2/2] net: wireless: fix to uses struct

[Ozgur Karatas]

My previous patch is invalid, I'm sorry.
The last patc will be fellow because "regulatory_request" is defined as a 
"static struct".

Signed-off-by: Ozgur Karatas 
---
 net/wireless/reg.c  | 10 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
 
-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;

@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
 
-   reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+   reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
 
-- 
2.1.4

Re: [PATCH 2/2] net: wireless: fix to uses struct

[Ozgur Karatas]

22.12.2016, 00:34, "Paul Bolle" <pebo...@tiscali.nl>:
> On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote:
>>  I compiled and didn't to errors.
>
> Really?

I'm very sorry. The "regulatory_request" is defined a static struct. I missed.

line: static struct regulatory_request core_request_world = {

I send to wrong line please can ignore last message and should be fix to as 
follows:

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
 
-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
 {
struct regulatory_request *request;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char 
*alpha2)
 
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
 
-   reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+   reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
 
-- 
2.1.4

> $ make net/wireless/reg.o
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALL scripts/checksyscalls.sh
>   CC net/wireless/reg.o
> net/wireless/reg.c: In function ‘regulatory_hint_core’:
> net/wireless/reg.c:2294:28: error: ‘regulatory_request’ undeclared (first use 
> in this function)
>   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~
> net/wireless/reg.c:2294:28: note: each undeclared identifier is reported only 
> once for each function it appears in
> net/wireless/reg.c: In function ‘regulatory_hint_user’:
> net/wireless/reg.c:2316:28: error: ‘regulatory_request’ undeclared (first use 
> in this function)
>   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~
> net/wireless/reg.c: In function ‘regulatory_hint’:
> net/wireless/reg.c:2388:28: error: ‘regulatory_request’ undeclared (first use 
> in this function)
>   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~
> scripts/Makefile.build:293: recipe for target 'net/wireless/reg.o' failed
> make[1]: *** [net/wireless/reg.o] Error 1
> Makefile:1640: recipe for target 'net/wireless/reg.o' failed
> make: *** [net/wireless/reg.o] Error 2

$ make M=net/wireless/
  CC  net/wireless//core.o
  CC  net/wireless//sysfs.o
  CC  net/wireless//radiotap.o
  CC  net/wireless//util.o
  CC  net/wireless//reg.o
  CC  net/wireless//scan.o
  CC  net/wireless//nl80211.o
  CC  net/wireless//mlme.o
  CC  net/wireless//ibss.o
  CC  net/wireless//sme.o
  CC  net/wireless//chan.o
  CC  net/wireless//ethtool.o
  CC  net/wireless//mesh.o
  CC  net/wireless//ap.o
  CC  net/wireless//trace.o
  CC  net/wireless//ocb.o
  LD  net/wireless//cfg80211.o
  LD  net/wireless//built-in.o
  Building modules, stage 2.
  MODPOST 0 modules

$ make net/wireless/reg.o
scripts/kconfig/conf  --silentoldconfig Kconfig
*
* Restart config...
*
*
* Memory power savings
*

> Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?

I don't have a problem with C programming, So only I'm learning the kernel. 
Also, this is a lie if say "I'm expert to C".

I think be re-learned every day. wrong?

> Paul Bolle

Regards,

~ Ozgur

Re: [PATCH 2/2] net: wireless: fix to uses struct

[Ozgur Karatas]

22.12.2016, 00:34, "Paul Bolle" :
> On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote:
>>  I compiled and didn't to errors.
>
> Really?

I'm very sorry. The "regulatory_request" is defined a static struct. I missed.

line: static struct regulatory_request core_request_world = {

I send to wrong line please can ignore last message and should be fix to as 
follows:

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
 
-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
 {
struct regulatory_request *request;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char 
*alpha2)
 
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
 
-   reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+   reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
 
-- 
2.1.4

> $ make net/wireless/reg.o
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALL scripts/checksyscalls.sh
>   CC net/wireless/reg.o
> net/wireless/reg.c: In function ‘regulatory_hint_core’:
> net/wireless/reg.c:2294:28: error: ‘regulatory_request’ undeclared (first use 
> in this function)
>   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~
> net/wireless/reg.c:2294:28: note: each undeclared identifier is reported only 
> once for each function it appears in
> net/wireless/reg.c: In function ‘regulatory_hint_user’:
> net/wireless/reg.c:2316:28: error: ‘regulatory_request’ undeclared (first use 
> in this function)
>   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~
> net/wireless/reg.c: In function ‘regulatory_hint’:
> net/wireless/reg.c:2388:28: error: ‘regulatory_request’ undeclared (first use 
> in this function)
>   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~
> scripts/Makefile.build:293: recipe for target 'net/wireless/reg.o' failed
> make[1]: *** [net/wireless/reg.o] Error 1
> Makefile:1640: recipe for target 'net/wireless/reg.o' failed
> make: *** [net/wireless/reg.o] Error 2

$ make M=net/wireless/
  CC  net/wireless//core.o
  CC  net/wireless//sysfs.o
  CC  net/wireless//radiotap.o
  CC  net/wireless//util.o
  CC  net/wireless//reg.o
  CC  net/wireless//scan.o
  CC  net/wireless//nl80211.o
  CC  net/wireless//mlme.o
  CC  net/wireless//ibss.o
  CC  net/wireless//sme.o
  CC  net/wireless//chan.o
  CC  net/wireless//ethtool.o
  CC  net/wireless//mesh.o
  CC  net/wireless//ap.o
  CC  net/wireless//trace.o
  CC  net/wireless//ocb.o
  LD  net/wireless//cfg80211.o
  LD  net/wireless//built-in.o
  Building modules, stage 2.
  MODPOST 0 modules

$ make net/wireless/reg.o
scripts/kconfig/conf  --silentoldconfig Kconfig
*
* Restart config...
*
*
* Memory power savings
*

> Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?

I don't have a problem with C programming, So only I'm learning the kernel. 
Also, this is a lie if say "I'm expert to C".

I think be re-learned every day. wrong?

> Paul Bolle

Regards,

~ Ozgur

[PATCH 2/2] net: wireless: fix to uses struct

[Ozgur Karatas]

The patch fixed to struct uses in reg.c, I think doesn't need to be use to 
"struct". 
There is dataype not have to logical link and each is different definitons.

I'm undecided on this patch. I compiled and didn't to errors.
 
Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 net/wireless/reg.c  | 10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
 
-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
 {
struct regulatory_request *request;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char 
*alpha2)
 
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
 
-   reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+   reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
 
-- 
2.1.4

[PATCH 2/2] net: wireless: fix to uses struct

[Ozgur Karatas]

The patch fixed to struct uses in reg.c, I think doesn't need to be use to 
"struct". 
There is dataype not have to logical link and each is different definitons.

I'm undecided on this patch. I compiled and didn't to errors.
 
Signed-off-by: Ozgur Karatas 
---
 net/wireless/reg.c  | 10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
 
-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
 {
struct regulatory_request *request;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char 
*alpha2)
 
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
 
-   request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
 
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
 
-   reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+   reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
 
-- 
2.1.4

[PATCH 1/2] net: wireless: fixed to checkpatch errors

[Ozgur Karatas]

Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next 
line.
The patch fix to readability and Coding Style.

Sİgned-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 net/wireless/chan.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 5497d022..8c7ac7f 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -891,7 +891,8 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
  : CHAN_MODE_EXCLUSIVE;
 
/* consider worst-case - IBSS can try to return to the
-* original user-specified channel as creator */
+* original user-specified channel as creator 
+*/
if (wdev->ibss_dfs_possible)
*radar_detect |= BIT(wdev->chandef.width);
return;
-- 
2.1.4

[PATCH 1/2] net: wireless: fixed to checkpatch errors

[Ozgur Karatas]

Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next 
line.
The patch fix to readability and Coding Style.

Sİgned-off-by: Ozgur Karatas 
---
 net/wireless/chan.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 5497d022..8c7ac7f 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -891,7 +891,8 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
  : CHAN_MODE_EXCLUSIVE;
 
/* consider worst-case - IBSS can try to return to the
-* original user-specified channel as creator */
+* original user-specified channel as creator 
+*/
if (wdev->ibss_dfs_possible)
*radar_detect |= BIT(wdev->chandef.width);
return;
-- 
2.1.4

Re: [PATCH] Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Ozgur Karatas]

20.12.2016, 01:13, "Jonathan Corbet" <cor...@lwn.net>:
> On Mon, 19 Dec 2016 23:53:40 +0200
> Cihangir Akturk <cakt...@gmail.com> wrote:
>
>>  In the actual implementation ether_addr_equal function tests for equality 
>> to 0
>>  when returning. It seems in commit 0d74c4 it is somehow overlooked to change
>>  this operator to reflect the actual function.
>
> I received this patch two days ago; has something changed that you're
> sending it again?

My opinion, the patch its update. The assignment of "!=0" has already been 
fixed with patch. 
I tested it.

> Meanwhile, there was a question from Ozgur Karatas on the patch, but I've
> not yet seen your response.

If you see fit your approval.

> Thanks,
>
> jon

Regards,

~Ozgur

Re: [PATCH] Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Ozgur Karatas]

20.12.2016, 01:13, "Jonathan Corbet" :
> On Mon, 19 Dec 2016 23:53:40 +0200
> Cihangir Akturk  wrote:
>
>>  In the actual implementation ether_addr_equal function tests for equality 
>> to 0
>>  when returning. It seems in commit 0d74c4 it is somehow overlooked to change
>>  this operator to reflect the actual function.
>
> I received this patch two days ago; has something changed that you're
> sending it again?

My opinion, the patch its update. The assignment of "!=0" has already been 
fixed with patch. 
I tested it.

> Meanwhile, there was a question from Ozgur Karatas on the patch, but I've
> not yet seen your response.

If you see fit your approval.

> Thanks,
>
> jon

Regards,

~Ozgur

Re: Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Ozgur Karatas]

20.12.2016, 02:22, "Cihangir Akturk" <cakt...@gmail.com>:
> On Sun, Dec 18, 2016 at 12:52:12AM +0200, Ozgur Karatas wrote:
>>  17.12.2016, 19:43, "Cihangir Akturk" <cakt...@gmail.com>:
>>  > In the actual implementation ether_addr_equal function tests for equality 
>> to 0
>>  > when returning. It seems in commit 0d74c4 it is somehow overlooked to 
>> change
>>  > this operator to reflect the actual function.
>>
>>  why this "return" function need to be ==0? I think, u16 functions read 
>> memory but "0" is should not be equalty.
>
> XOR is true only when inputs differ. That means if inputs are the
> same, then it outputs false (0) or whatever you call it. Then we
> perform OR operation between those outputs. So if the result is 0 then
> addr1 and addr2 is equal.

Thanks for this explanation to your patch. In this case the patch mentioned is 
valid. 
I checked, turned to "!=0" errors.

un-mem.c:29:18: error: ‘!’ (first use in this function)
 return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;

^
Also, don't need to send patch it secon time :)

>>  This way, -for the code to work- memory should be everytime unaligned !=0.
>
> Sorry I didn't quite get the point.

Regards,

~Ozgur

Re: Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Ozgur Karatas]

20.12.2016, 02:22, "Cihangir Akturk" :
> On Sun, Dec 18, 2016 at 12:52:12AM +0200, Ozgur Karatas wrote:
>>  17.12.2016, 19:43, "Cihangir Akturk" :
>>  > In the actual implementation ether_addr_equal function tests for equality 
>> to 0
>>  > when returning. It seems in commit 0d74c4 it is somehow overlooked to 
>> change
>>  > this operator to reflect the actual function.
>>
>>  why this "return" function need to be ==0? I think, u16 functions read 
>> memory but "0" is should not be equalty.
>
> XOR is true only when inputs differ. That means if inputs are the
> same, then it outputs false (0) or whatever you call it. Then we
> perform OR operation between those outputs. So if the result is 0 then
> addr1 and addr2 is equal.

Thanks for this explanation to your patch. In this case the patch mentioned is 
valid. 
I checked, turned to "!=0" errors.

un-mem.c:29:18: error: ‘!’ (first use in this function)
 return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;

^
Also, don't need to send patch it secon time :)

>>  This way, -for the code to work- memory should be everytime unaligned !=0.
>
> Sorry I didn't quite get the point.

Regards,

~Ozgur

Re: [PATCH 1/1] kernel: futex: fixed to else and initcall

[Ozgur Karatas]

20.12.2016, 11:21, "Thomas Gleixner" <t...@linutronix.de>:
> On Mon, 19 Dec 2016, Ozgur Karatas wrote:
>
>>  else doesn't need to be used, if should be enclosed in parentheses.
>
> Really?
>
>
> So you change the code from
>
> if (err < 0)
> return err;
> else
> err = 0;
>
> to
>
> if (err < 0) {
> return err;
> err = 0;
> }
>
> How on earth is that equivivalent and how would that 'err = 0;' statement
> be ever executed?

Oh my god, I missed this point, sorry! 
Thank you so much for correct me.

This "return err;" will give to "err" and err defined to err = "0".
Then removed to "else" and return = err;  and should it be like this?

#define err = 0;

 if (err < 0) {
 return err;
 }

Regards,

Ozgur

> You clearly ran checkpatch.pl on this file and the output for this
> construct is:
>
> WARNING: else is not generally useful after a break or return
> #550: FILE: kernel/futex.c:550:
> + return err;
> + else
>
> So the proper change would have been:
>
> if (err < 0)
> return err;
>
> err = 0;
>
> and not the trainwreck you created.
>
> checkpatch.pl does not substitute basic knowlegde of C.
>
> Thanks,
>
> tglx

Re: [PATCH 1/1] kernel: futex: fixed to else and initcall

[Ozgur Karatas]

20.12.2016, 11:21, "Thomas Gleixner" :
> On Mon, 19 Dec 2016, Ozgur Karatas wrote:
>
>>  else doesn't need to be used, if should be enclosed in parentheses.
>
> Really?
>
>
> So you change the code from
>
> if (err < 0)
> return err;
> else
> err = 0;
>
> to
>
> if (err < 0) {
> return err;
> err = 0;
> }
>
> How on earth is that equivivalent and how would that 'err = 0;' statement
> be ever executed?

Oh my god, I missed this point, sorry! 
Thank you so much for correct me.

This "return err;" will give to "err" and err defined to err = "0".
Then removed to "else" and return = err;  and should it be like this?

#define err = 0;

 if (err < 0) {
 return err;
 }

Regards,

Ozgur

> You clearly ran checkpatch.pl on this file and the output for this
> construct is:
>
> WARNING: else is not generally useful after a break or return
> #550: FILE: kernel/futex.c:550:
> + return err;
> + else
>
> So the proper change would have been:
>
> if (err < 0)
> return err;
>
> err = 0;
>
> and not the trainwreck you created.
>
> checkpatch.pl does not substitute basic knowlegde of C.
>
> Thanks,
>
> tglx

[PATCH 1/1] kernel: futex: fixed to else and initcall

[Ozgur Karatas]

The include/linux/init.h file have to content; to not used __initcall functions.
I think, needs to be replaced to device_initcall.

device_initcall() or more appropriate function instead of __initcall.

else doesn't need to be used, if should be enclosed in parentheses.
Also, I used checkpatch scripts and fixed to errors.

ERROR: "(foo*)" should be "(foo *)"
ERROR: "foo * bar" should be "foo *bar"
ERROR: "foo * bar" should be "foo *bar"

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 kernel/futex.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 2c4be46..fd8a451 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -390,7 +390,7 @@ static inline int hb_waiters_pending(struct 
futex_hash_bucket *hb)
  */
 static struct futex_hash_bucket *hash_futex(union futex_key *key)
 {
-   u32 hash = jhash2((u32*)>both.word,
+   u32 hash = jhash2((u32 *)>both.word,
  (sizeof(key->both.word)+sizeof(key->both.ptr))/4,
  key->both.offset);
return _queues[hash & (futex_hashsize - 1)];
@@ -545,10 +545,10 @@ get_futex_key(u32 __user *uaddr, int fshared, union 
futex_key *key, int rw)
err = get_user_pages_fast(address, 1, 0, );
ro = 1;
}
-   if (err < 0)
+   if (err < 0) {
return err;
-   else
err = 0;
+   }
 
/*
 * The treatment of mapping from this point on is critical. The page
@@ -800,7 +800,7 @@ static int refill_pi_state_cache(void)
return 0;
 }
 
-static struct futex_pi_state * alloc_pi_state(void)
+static struct futex_pi_state *alloc_pi_state(void)
 {
struct futex_pi_state *pi_state = current->pi_state_cache;
 
@@ -854,7 +854,7 @@ static void put_pi_state(struct futex_pi_state *pi_state)
  * Look up the task based on what TID userspace gave us.
  * We dont trust it.
  */
-static struct task_struct * futex_find_get_task(pid_t pid)
+static struct task_struct *futex_find_get_task(pid_t pid)
 {
struct task_struct *p;
 
@@ -3323,4 +3323,4 @@ static int __init futex_init(void)
 
return 0;
 }
-__initcall(futex_init);
+device_initcall(futex_init);
-- 
2.1.4

[PATCH 1/1] kernel: futex: fixed to else and initcall

[Ozgur Karatas]

The include/linux/init.h file have to content; to not used __initcall functions.
I think, needs to be replaced to device_initcall.

device_initcall() or more appropriate function instead of __initcall.

else doesn't need to be used, if should be enclosed in parentheses.
Also, I used checkpatch scripts and fixed to errors.

ERROR: "(foo*)" should be "(foo *)"
ERROR: "foo * bar" should be "foo *bar"
ERROR: "foo * bar" should be "foo *bar"

Signed-off-by: Ozgur Karatas 
---
 kernel/futex.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 2c4be46..fd8a451 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -390,7 +390,7 @@ static inline int hb_waiters_pending(struct 
futex_hash_bucket *hb)
  */
 static struct futex_hash_bucket *hash_futex(union futex_key *key)
 {
-   u32 hash = jhash2((u32*)>both.word,
+   u32 hash = jhash2((u32 *)>both.word,
  (sizeof(key->both.word)+sizeof(key->both.ptr))/4,
  key->both.offset);
return _queues[hash & (futex_hashsize - 1)];
@@ -545,10 +545,10 @@ get_futex_key(u32 __user *uaddr, int fshared, union 
futex_key *key, int rw)
err = get_user_pages_fast(address, 1, 0, );
ro = 1;
}
-   if (err < 0)
+   if (err < 0) {
return err;
-   else
err = 0;
+   }
 
/*
 * The treatment of mapping from this point on is critical. The page
@@ -800,7 +800,7 @@ static int refill_pi_state_cache(void)
return 0;
 }
 
-static struct futex_pi_state * alloc_pi_state(void)
+static struct futex_pi_state *alloc_pi_state(void)
 {
struct futex_pi_state *pi_state = current->pi_state_cache;
 
@@ -854,7 +854,7 @@ static void put_pi_state(struct futex_pi_state *pi_state)
  * Look up the task based on what TID userspace gave us.
  * We dont trust it.
  */
-static struct task_struct * futex_find_get_task(pid_t pid)
+static struct task_struct *futex_find_get_task(pid_t pid)
 {
struct task_struct *p;
 
@@ -3323,4 +3323,4 @@ static int __init futex_init(void)
 
return 0;
 }
-__initcall(futex_init);
+device_initcall(futex_init);
-- 
2.1.4

Re: [PATCH] drivers: staging: fbtft: fix checkpatch error and udelay

[Ozgur Karatas]

19.12.2016, 08:35, "Greg KH" <gre...@linuxfoundation.org>:
> On Sun, Dec 18, 2016 at 11:47:30AM -0600, Scott Matheina wrote:
>>  These changes where identified by checkpatch.pl as needed changes to
>>  align the code with the linux development coding style. The several
>>  lines of text where aligned with the precending parenthesis.
>>
>>  Signed-off-by: Scott Matheina <sc...@matheina.com>
>>
>>   Changes to be committed:
>>  modified: drivers/staging/fbtft/fb_agm1264k-fl.c
>
> Why are these lines in the changelog text?

I checked with checkpatch script to code and give a some errors.
So, the code have to "udelay(20)".

udelay(20);

I read to Documentation/timers/timers-howto.txt and
this line incorrect, usleep_range need must be add defined U_DELAY and fixed.

udelay(U_DELAY, U_DELAY + 10);

finally:

$ checkpatch.pl  drivers/staging/fbtft/fb_agm1264k-fl.c  | grep total
total: 0 errors

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>

---
 drivers/staging/fbtft/fb_agm1264k-fl.c | 31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index 7561385..2d46d03 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -36,10 +36,11 @@
 #define FPS20
 
 #define EPIN   gpio.wr
-#define RS gpio.dc
-#define RW gpio.aux[2]
-#define CS0gpio.aux[0]
-#define CS1gpio.aux[1]
+#define RS gpio.dc
+#define RW gpio.aux[2]
+#define CS0gpio.aux[0]
+#define CS1gpio.aux[1]
+#define U_DELAY
 
 /* diffusing error (Floyd-Steinberg) */
 #define DIFFUSING_MATRIX_WIDTH 2
@@ -94,7 +95,7 @@ static void reset(struct fbtft_par *par)
dev_dbg(par->info->device, "%s()\n", __func__);
 
gpio_set_value(par->gpio.reset, 0);
-   udelay(20);
+   udelay(U_DELAY, U_DELAY + 10);
gpio_set_value(par->gpio.reset, 1);
mdelay(120);
 }
@@ -185,8 +186,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
buf[i] = (u8)va_arg(args, unsigned int);
 
va_end(args);
-   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
-   par->info->device, u8, buf, len, "%s: ", __func__);
+   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device, 
u8, buf, len, "%s: ", __func__);
}
 
va_start(args, len);
@@ -245,8 +245,7 @@ static void set_addr_win(struct fbtft_par *par, int xs, int 
ys, int xe, int ye)
 }
 
 static void
-construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src,
-   int xs, int xe, int y)
+construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src, int 
xs, int xe, int y)
 {
int x, i;
 
@@ -326,9 +325,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
signed char coeff;
 
/* skip pixels out of zone */
-   if (x + i < 0 ||
-   x + i >= par->info->var.xres
-   || y + j >= par->info->var.yres)
+   if (x + i < 0 || x + i >= 
par->info->var.xres || y + j >= par->info->var.yres)
continue;
write_pos = _buf[
(y + j) * par->info->var.xres +
@@ -354,8 +351,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
for (y = addr_win.ys_page; y <= addr_win.ye_page; ++y) {
/* left half of display */
if (addr_win.xs < par->info->var.xres / 2) {
-   construct_line_bitmap(par, buf, convert_buf,
-   addr_win.xs, par->info->var.xres / 2, y);
+   construct_line_bitmap(par, buf, convert_buf, 
addr_win.xs, par->info->var.xres / 2, y);
 
len = par->info->var.xres / 2 - addr_win.xs;
 
@@ -375,9 +371,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
}
/* right half of display */
if (addr_win.xe >= par->info->var.xres / 2) {
-   construct_line_bitmap(par, buf,
-   convert_buf, par->info->var.xres / 2,
-   addr_win.xe + 1, y);
+   construct_line_bitmap(par, buf, c

Re: [PATCH] drivers: staging: fbtft: fix checkpatch error and udelay

[Ozgur Karatas]

19.12.2016, 08:35, "Greg KH" :
> On Sun, Dec 18, 2016 at 11:47:30AM -0600, Scott Matheina wrote:
>>  These changes where identified by checkpatch.pl as needed changes to
>>  align the code with the linux development coding style. The several
>>  lines of text where aligned with the precending parenthesis.
>>
>>  Signed-off-by: Scott Matheina 
>>
>>   Changes to be committed:
>>  modified: drivers/staging/fbtft/fb_agm1264k-fl.c
>
> Why are these lines in the changelog text?

I checked with checkpatch script to code and give a some errors.
So, the code have to "udelay(20)".

udelay(20);

I read to Documentation/timers/timers-howto.txt and
this line incorrect, usleep_range need must be add defined U_DELAY and fixed.

udelay(U_DELAY, U_DELAY + 10);

finally:

$ checkpatch.pl  drivers/staging/fbtft/fb_agm1264k-fl.c  | grep total
total: 0 errors

Signed-off-by: Ozgur Karatas 

---
 drivers/staging/fbtft/fb_agm1264k-fl.c | 31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index 7561385..2d46d03 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -36,10 +36,11 @@
 #define FPS20
 
 #define EPIN   gpio.wr
-#define RS gpio.dc
-#define RW gpio.aux[2]
-#define CS0gpio.aux[0]
-#define CS1gpio.aux[1]
+#define RS gpio.dc
+#define RW gpio.aux[2]
+#define CS0gpio.aux[0]
+#define CS1gpio.aux[1]
+#define U_DELAY
 
 /* diffusing error (Floyd-Steinberg) */
 #define DIFFUSING_MATRIX_WIDTH 2
@@ -94,7 +95,7 @@ static void reset(struct fbtft_par *par)
dev_dbg(par->info->device, "%s()\n", __func__);
 
gpio_set_value(par->gpio.reset, 0);
-   udelay(20);
+   udelay(U_DELAY, U_DELAY + 10);
gpio_set_value(par->gpio.reset, 1);
mdelay(120);
 }
@@ -185,8 +186,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
buf[i] = (u8)va_arg(args, unsigned int);
 
va_end(args);
-   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
-   par->info->device, u8, buf, len, "%s: ", __func__);
+   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device, 
u8, buf, len, "%s: ", __func__);
}
 
va_start(args, len);
@@ -245,8 +245,7 @@ static void set_addr_win(struct fbtft_par *par, int xs, int 
ys, int xe, int ye)
 }
 
 static void
-construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src,
-   int xs, int xe, int y)
+construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src, int 
xs, int xe, int y)
 {
int x, i;
 
@@ -326,9 +325,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
signed char coeff;
 
/* skip pixels out of zone */
-   if (x + i < 0 ||
-   x + i >= par->info->var.xres
-   || y + j >= par->info->var.yres)
+   if (x + i < 0 || x + i >= 
par->info->var.xres || y + j >= par->info->var.yres)
continue;
write_pos = _buf[
(y + j) * par->info->var.xres +
@@ -354,8 +351,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
for (y = addr_win.ys_page; y <= addr_win.ye_page; ++y) {
/* left half of display */
if (addr_win.xs < par->info->var.xres / 2) {
-   construct_line_bitmap(par, buf, convert_buf,
-   addr_win.xs, par->info->var.xres / 2, y);
+   construct_line_bitmap(par, buf, convert_buf, 
addr_win.xs, par->info->var.xres / 2, y);
 
len = par->info->var.xres / 2 - addr_win.xs;
 
@@ -375,9 +371,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
}
/* right half of display */
if (addr_win.xe >= par->info->var.xres / 2) {
-   construct_line_bitmap(par, buf,
-   convert_buf, par->info->var.xres / 2,
-   addr_win.xe + 1, y);
+   construct_line_bitmap(par, buf, convert_buf, 
par->info->var.xres / 2, addr_win.xe + 1, y);
 
  

Re: Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Ozgur Karatas]

17.12.2016, 19:43, "Cihangir Akturk" :
> In the actual implementation ether_addr_equal function tests for equality to 0
> when returning. It seems in commit 0d74c4 it is somehow overlooked to change
> this operator to reflect the actual function.

why this "return" function need to be ==0? I think, u16 functions read memory 
but "0" is should not be equalty.
This way, -for the code to work- memory should be everytime unaligned !=0.


> Signed-off-by: Cihangir Akturk 
> ---
>  Documentation/unaligned-memory-access.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/unaligned-memory-access.txt 
> b/Documentation/unaligned-memory-access.txt
> index a445da0..3f76c0c 100644
> --- a/Documentation/unaligned-memory-access.txt
> +++ b/Documentation/unaligned-memory-access.txt
> @@ -151,7 +151,7 @@ bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
>  #else
>  const u16 *a = (const u16 *)addr1;
>  const u16 *b = (const u16 *)addr2;
> - return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
> + return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) == 0;
>  #endif
>  }
>
> --
> 2.1.4

Re: Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Ozgur Karatas]

17.12.2016, 19:43, "Cihangir Akturk" :
> In the actual implementation ether_addr_equal function tests for equality to 0
> when returning. It seems in commit 0d74c4 it is somehow overlooked to change
> this operator to reflect the actual function.

why this "return" function need to be ==0? I think, u16 functions read memory 
but "0" is should not be equalty.
This way, -for the code to work- memory should be everytime unaligned !=0.


> Signed-off-by: Cihangir Akturk 
> ---
>  Documentation/unaligned-memory-access.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/unaligned-memory-access.txt 
> b/Documentation/unaligned-memory-access.txt
> index a445da0..3f76c0c 100644
> --- a/Documentation/unaligned-memory-access.txt
> +++ b/Documentation/unaligned-memory-access.txt
> @@ -151,7 +151,7 @@ bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
>  #else
>  const u16 *a = (const u16 *)addr1;
>  const u16 *b = (const u16 *)addr2;
> - return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
> + return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) == 0;
>  #endif
>  }
>
> --
> 2.1.4

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

[Ozgur Karatas]

16.12.2016, 21:08, "Sergei Shtylyov" <sergei.shtyl...@cogentembedded.com>:
> Hello.

Hi

> On 12/16/2016 09:21 PM, Ozgur Karatas wrote:
>
>>  This patch fixed to keyboard typo, brackets not closed.
>>  I think, it should be close to parenthes.
>>
>>  Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
>>  ---
>>   tools/net/bpf_dbg.c | 2 +-
>>   1 files changed, 1 insertion(+), 1 deletions(-)
>>
>>  diff --git a/tools/net/bpf_dbg.c b/tools/net/bpf_dbg.c
>>  index 4f254bc..f715f46 100644
>>  --- a/tools/net/bpf_dbg.c
>>  +++ b/tools/net/bpf_dbg.c
>>  @@ -1213,7 +1213,7 @@ static int cmd_disassemble(char *line_string)
>>
>>   if (!bpf_prog_loaded())
>>   return CMD_ERR;
>>  - if (strlen(line_string) > 0 &&
>>  + if (strlen(line_string) > 0 &&)
>
> Have tried to you compile that? :-/

Yes, i compiled but I apologize if there was NAK.
Also, checkpatch give a error.

I could be wrong, will review again.

Best Regards!

>>   (line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
>
> I think the code was correct before your patch...
>
>>   single_line = true;
>>   if (single_line)
>
> MBR, Sergei

~Ozgur

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

[Ozgur Karatas]

16.12.2016, 21:08, "Sergei Shtylyov" :
> Hello.

Hi

> On 12/16/2016 09:21 PM, Ozgur Karatas wrote:
>
>>  This patch fixed to keyboard typo, brackets not closed.
>>  I think, it should be close to parenthes.
>>
>>  Signed-off-by: Ozgur Karatas 
>>  ---
>>   tools/net/bpf_dbg.c | 2 +-
>>   1 files changed, 1 insertion(+), 1 deletions(-)
>>
>>  diff --git a/tools/net/bpf_dbg.c b/tools/net/bpf_dbg.c
>>  index 4f254bc..f715f46 100644
>>  --- a/tools/net/bpf_dbg.c
>>  +++ b/tools/net/bpf_dbg.c
>>  @@ -1213,7 +1213,7 @@ static int cmd_disassemble(char *line_string)
>>
>>   if (!bpf_prog_loaded())
>>   return CMD_ERR;
>>  - if (strlen(line_string) > 0 &&
>>  + if (strlen(line_string) > 0 &&)
>
> Have tried to you compile that? :-/

Yes, i compiled but I apologize if there was NAK.
Also, checkpatch give a error.

I could be wrong, will review again.

Best Regards!

>>   (line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
>
> I think the code was correct before your patch...
>
>>   single_line = true;
>>   if (single_line)
>
> MBR, Sergei

~Ozgur

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

[Ozgur Karatas]

16.12.2016, 20:35, "Joe Perches" <j...@perches.com>:
> On Fri, 2016-12-16 at 20:21 +0200, Ozgur Karatas wrote:
>>  This patch fixed to keyboard typo, brackets not closed.
>>  I think, it should be close to parenthes.
>
> No.
>
> Please compile and test your patches on your own system
> before you send them.

Also, checkpatch script give a error, it should not forget.

$ ./scripts/checkpatch.pl --file --terse tools/net/bpf_dbg.c
tools/net/bpf_dbg.c:1216: ERROR: do not use assignment in if condition

After fix:

$ ./scripts/checkpatch.pl --file --terse tools/net/bpf_dbg.c 
total: 0 errors, 6 warnings, 1395 lines checked

Regards,

~Ozgur

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

[Ozgur Karatas]

16.12.2016, 20:35, "Joe Perches" :
> On Fri, 2016-12-16 at 20:21 +0200, Ozgur Karatas wrote:
>>  This patch fixed to keyboard typo, brackets not closed.
>>  I think, it should be close to parenthes.
>
> No.
>
> Please compile and test your patches on your own system
> before you send them.

Also, checkpatch script give a error, it should not forget.

$ ./scripts/checkpatch.pl --file --terse tools/net/bpf_dbg.c
tools/net/bpf_dbg.c:1216: ERROR: do not use assignment in if condition

After fix:

$ ./scripts/checkpatch.pl --file --terse tools/net/bpf_dbg.c 
total: 0 errors, 6 warnings, 1395 lines checked

Regards,

~Ozgur

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

[Ozgur Karatas]

16.12.2016, 20:35, "Joe Perches" <j...@perches.com>:
> On Fri, 2016-12-16 at 20:21 +0200, Ozgur Karatas wrote:
>>  This patch fixed to keyboard typo, brackets not closed.
>>  I think, it should be close to parenthes.
>
> No.
>
> Please compile and test your patches on your own system
> before you send them.

Dear Perches,

I have already tested and it was not a part of the code anyway. if there is no 
parentheses, the code works incorrectly and give a error. 
I'm sorry, have a little problem with my english but "line_string" variables 
would not equal NULL, 10. So the code it skips it and runs to "bpf_prog_len".
If it should be equal "0 &&" and already be completed (>) right?

if (strlen(line_string) > 0 &&
(line = strtoul(line_string, NULL, 10)) < bpf_prog_len)

Testing:

$ make M=tools/
tools//Makefile:6: scripts/Makefile.include: No such file or directory
$ cp tools/scripts/Makefile.include scripts/Makefile
$ make M=tools/
  Building modules, stage 2.
  MODPOST 0 modules

I try to module (insmod) and worked.

Regards,

 ~Ozgur

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

[Ozgur Karatas]

16.12.2016, 20:35, "Joe Perches" :
> On Fri, 2016-12-16 at 20:21 +0200, Ozgur Karatas wrote:
>>  This patch fixed to keyboard typo, brackets not closed.
>>  I think, it should be close to parenthes.
>
> No.
>
> Please compile and test your patches on your own system
> before you send them.

Dear Perches,

I have already tested and it was not a part of the code anyway. if there is no 
parentheses, the code works incorrectly and give a error. 
I'm sorry, have a little problem with my english but "line_string" variables 
would not equal NULL, 10. So the code it skips it and runs to "bpf_prog_len".
If it should be equal "0 &&" and already be completed (>) right?

if (strlen(line_string) > 0 &&
(line = strtoul(line_string, NULL, 10)) < bpf_prog_len)

Testing:

$ make M=tools/
tools//Makefile:6: scripts/Makefile.include: No such file or directory
$ cp tools/scripts/Makefile.include scripts/Makefile
$ make M=tools/
  Building modules, stage 2.
  MODPOST 0 modules

I try to module (insmod) and worked.

Regards,

 ~Ozgur

[PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

[Ozgur Karatas]

This patch fixed to keyboard typo, brackets not closed. 
I think, it should be close to parenthes.

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 tools/net/bpf_dbg.c   | 2 +-
 1 files changed, 1 insertion(+), 1 deletions(-)

diff --git a/tools/net/bpf_dbg.c b/tools/net/bpf_dbg.c
index 4f254bc..f715f46 100644
--- a/tools/net/bpf_dbg.c
+++ b/tools/net/bpf_dbg.c
@@ -1213,7 +1213,7 @@ static int cmd_disassemble(char *line_string)
 
if (!bpf_prog_loaded())
return CMD_ERR;
-   if (strlen(line_string) > 0 &&
+   if (strlen(line_string) > 0 &&)
(line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
single_line = true;
if (single_line)
-- 
2.1.4

[PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

[Ozgur Karatas]

This patch fixed to keyboard typo, brackets not closed. 
I think, it should be close to parenthes.

Signed-off-by: Ozgur Karatas 
---
 tools/net/bpf_dbg.c   | 2 +-
 1 files changed, 1 insertion(+), 1 deletions(-)

diff --git a/tools/net/bpf_dbg.c b/tools/net/bpf_dbg.c
index 4f254bc..f715f46 100644
--- a/tools/net/bpf_dbg.c
+++ b/tools/net/bpf_dbg.c
@@ -1213,7 +1213,7 @@ static int cmd_disassemble(char *line_string)
 
if (!bpf_prog_loaded())
return CMD_ERR;
-   if (strlen(line_string) > 0 &&
+   if (strlen(line_string) > 0 &&)
(line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
single_line = true;
if (single_line)
-- 
2.1.4

Re: [PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

12.12.2016, 22:50, "Joe Perches" <j...@perches.com>:
> On Mon, 2016-12-12 at 14:41 -0600, Eric Sandeen wrote:
>>  On 12/12/16 2:34 PM, Ozgur Karatas wrote:
>
> []
>>  > Can you tell me the true code style? should use to (* uuid)?
>>  > I'm learn to new and I'm newbies :)
>>
>>  Well, rule #1 for newbies is "code style patches aren't
>>  very useful, and usually are not welcomed by the project."
>
> I'd amend that to
>
> "newbies should only use checkpatch on files in drivers/staging/"
>
> and are generally welcome to do exactly that in order to learn
> how to submit patches appropriately before finding something
> actually useful to change in other areas of the kernel.

Dear Joe;
I understand, thank you very much but I use XFS and I'm trying to learn how to 
code to XFS filesystems. 
Maybe, I can try for XFS and I need to very learn more :)

Regards,

Ozgur Karatas

Re: [PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

12.12.2016, 22:50, "Joe Perches" :
> On Mon, 2016-12-12 at 14:41 -0600, Eric Sandeen wrote:
>>  On 12/12/16 2:34 PM, Ozgur Karatas wrote:
>
> []
>>  > Can you tell me the true code style? should use to (* uuid)?
>>  > I'm learn to new and I'm newbies :)
>>
>>  Well, rule #1 for newbies is "code style patches aren't
>>  very useful, and usually are not welcomed by the project."
>
> I'd amend that to
>
> "newbies should only use checkpatch on files in drivers/staging/"
>
> and are generally welcome to do exactly that in order to learn
> how to submit patches appropriately before finding something
> actually useful to change in other areas of the kernel.

Dear Joe;
I understand, thank you very much but I use XFS and I'm trying to learn how to 
code to XFS filesystems. 
Maybe, I can try for XFS and I need to very learn more :)

Regards,

Ozgur Karatas

Re: [PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

12.12.2016, 22:41, "Eric Sandeen" <sand...@sandeen.net>:
> Well, rule #1 for newbies is "code style patches aren't
> very useful, and usually are not welcomed by the project."
>
> Making style changes just because checkpatch told you to is
> not particularly helpful. If it were important, it would have
> been done by now. If it hasn't been done by now, odds are
> it's not important. :)
>
> If you are writing /new/ code, then sure, conform to the kernel
> style, /aided/ by checkpatch.pl, and using your discretion as
> well.
>
> If you are just now looking at xfs/* code, best not to start
> with "style" cleanups. You'll find this to be true in general
> across the kernel, maintainers are usually not thrilled to have
> this kind of patch.

Dear Eric;
this information was very good and thank you, I will try for the better :)

> If you want to start with a new project, learn about the code,
> learn what it /does/, learn how to use it. use it. Find things
> that don't work as expected, or could work better. Look into
> bug reports and if you understand them, and the code involved,
> try to write and test a fix. But don't go looking for whitespace
> nitpicks.

I get it now, I understand but I think the error was only uuid functions.
Now, me more careful.

>>  Sorry,

>
> No need to be sorry, this is how we learn. ;) But really, making
> purely cosmetic changes for their own sake is not helpful in
> general.
>
> -Eric

I have mentioned above, thank you for all the information. 
You are helping me and  your mentoring in some way.

Regards

Ozgur Karatas

Re: [PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

12.12.2016, 22:41, "Eric Sandeen" :
> Well, rule #1 for newbies is "code style patches aren't
> very useful, and usually are not welcomed by the project."
>
> Making style changes just because checkpatch told you to is
> not particularly helpful. If it were important, it would have
> been done by now. If it hasn't been done by now, odds are
> it's not important. :)
>
> If you are writing /new/ code, then sure, conform to the kernel
> style, /aided/ by checkpatch.pl, and using your discretion as
> well.
>
> If you are just now looking at xfs/* code, best not to start
> with "style" cleanups. You'll find this to be true in general
> across the kernel, maintainers are usually not thrilled to have
> this kind of patch.

Dear Eric;
this information was very good and thank you, I will try for the better :)

> If you want to start with a new project, learn about the code,
> learn what it /does/, learn how to use it. use it. Find things
> that don't work as expected, or could work better. Look into
> bug reports and if you understand them, and the code involved,
> try to write and test a fix. But don't go looking for whitespace
> nitpicks.

I get it now, I understand but I think the error was only uuid functions.
Now, me more careful.

>>  Sorry,

>
> No need to be sorry, this is how we learn. ;) But really, making
> purely cosmetic changes for their own sake is not helpful in
> general.
>
> -Eric

I have mentioned above, thank you for all the information. 
You are helping me and  your mentoring in some way.

Regards

Ozgur Karatas

Re: [PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

12.12.2016, 20:14, "Joe Perches" <j...@perches.com>:
> On Mon, 2016-12-12 at 07:49 -0600, Eric Sandeen wrote:
>>  On 12/12/16 4:53 AM, Ozgur Karatas wrote:
>>  >
>>  > Hello,
>>  >
>>  > I have error to use uuid and I think the functions should be used when 
>> -i'm eye-catching- "(* uuid)".
>>  > I tested it.
>>  >
>>  > Regards,
>>  >
>>  > Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
>>
>>  NAK
>>
>>  This doesn't fix code style at all; there is no need and no
>>  precedence for i.e. (*uuid) in function arguments in the xfs code,
>>  and you have broken indentation in the loop within the function.
>
> Perhaps better would be to convert the xfs uuid_t typedef
> to the include/uapi/linux/uuid.h appropriate struct and
> maybe use a comparison to NULL_UUID_

Dear Joe;
Firstly, I have studied and so I thought it was correct to use it as (* uuid) 
in this regard Mr. Eric corrected me and he is explanatory to me.

fs/xfs/uuid.c:21: WARNING: do not add new typedefs
fs/xfs/uuid.c:36: ERROR: space prohibited before open square bracket '['
fs/xfs/uuid.c:54: WARNING: sizeof *uuid should be sizeof(*uuid)
fs/xfs/uuid.c:55: ERROR: trailing statements should be on next line
total: 2 errors, 2 warnings, 63 lines checked

>>  > diff --git a/fs/xfs/uuid.c b/fs/xfs/uuid.c
>
>
>>  > @@ -33,7 +33,7 @@ typedef struct {
>>  > * it just something that's needed for user-level file handles.
>>  > */
>>  > void
>>  > -uuid_getnodeuniq(uuid_t *uuid, int fsid [2])
>>  > +uuid_getnodeuniq(uuid_t (*uuid), int fsid [2])
>
> And to amplify Eric's comment:
>
> that bit is confusing as it makes uuid look
> like a function pointer.
>
>>  > {
>>  > xfs_uu_t *uup = (xfs_uu_t *)uuid;
>>  >
>>  > @@ -51,8 +51,8 @@ uuid_is_nil(uuid_t *uuid)
>>  > if (uuid == NULL)
>>  > return 0;
>>  > /* implied check of version number here... */
>>  > - for (i = 0; i < sizeof *uuid; i++)
>>  > - if (*cp++) return 0; /* not nil */
>>  > + for (i = 0; i < sizeof (*uuid); i++)
>>  > + if (*cp++) return 0; /* not nil */
>
> There shouldn't be a space after sizeof.

You can see below:
fs/xfs/uuid.c:54: WARNING: sizeof *uuid should be sizeof(*uuid)
Regards,

Ozgur

>>  > return 1; /* is nil */
>>  > }
>>  >

Re: [PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

12.12.2016, 20:14, "Joe Perches" :
> On Mon, 2016-12-12 at 07:49 -0600, Eric Sandeen wrote:
>>  On 12/12/16 4:53 AM, Ozgur Karatas wrote:
>>  >
>>  > Hello,
>>  >
>>  > I have error to use uuid and I think the functions should be used when 
>> -i'm eye-catching- "(* uuid)".
>>  > I tested it.
>>  >
>>  > Regards,
>>  >
>>  > Signed-off-by: Ozgur Karatas 
>>
>>  NAK
>>
>>  This doesn't fix code style at all; there is no need and no
>>  precedence for i.e. (*uuid) in function arguments in the xfs code,
>>  and you have broken indentation in the loop within the function.
>
> Perhaps better would be to convert the xfs uuid_t typedef
> to the include/uapi/linux/uuid.h appropriate struct and
> maybe use a comparison to NULL_UUID_

Dear Joe;
Firstly, I have studied and so I thought it was correct to use it as (* uuid) 
in this regard Mr. Eric corrected me and he is explanatory to me.

fs/xfs/uuid.c:21: WARNING: do not add new typedefs
fs/xfs/uuid.c:36: ERROR: space prohibited before open square bracket '['
fs/xfs/uuid.c:54: WARNING: sizeof *uuid should be sizeof(*uuid)
fs/xfs/uuid.c:55: ERROR: trailing statements should be on next line
total: 2 errors, 2 warnings, 63 lines checked

>>  > diff --git a/fs/xfs/uuid.c b/fs/xfs/uuid.c
>
>
>>  > @@ -33,7 +33,7 @@ typedef struct {
>>  > * it just something that's needed for user-level file handles.
>>  > */
>>  > void
>>  > -uuid_getnodeuniq(uuid_t *uuid, int fsid [2])
>>  > +uuid_getnodeuniq(uuid_t (*uuid), int fsid [2])
>
> And to amplify Eric's comment:
>
> that bit is confusing as it makes uuid look
> like a function pointer.
>
>>  > {
>>  > xfs_uu_t *uup = (xfs_uu_t *)uuid;
>>  >
>>  > @@ -51,8 +51,8 @@ uuid_is_nil(uuid_t *uuid)
>>  > if (uuid == NULL)
>>  > return 0;
>>  > /* implied check of version number here... */
>>  > - for (i = 0; i < sizeof *uuid; i++)
>>  > - if (*cp++) return 0; /* not nil */
>>  > + for (i = 0; i < sizeof (*uuid); i++)
>>  > + if (*cp++) return 0; /* not nil */
>
> There shouldn't be a space after sizeof.

You can see below:
fs/xfs/uuid.c:54: WARNING: sizeof *uuid should be sizeof(*uuid)
Regards,

Ozgur

>>  > return 1; /* is nil */
>>  > }
>>  >

Re: [PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

12.12.2016, 20:35, "Eric Sandeen" <sand...@sandeen.net>:
> On 12/12/16 12:14 PM, Joe Perches wrote:
>>  On Mon, 2016-12-12 at 07:49 -0600, Eric Sandeen wrote:
>>>  On 12/12/16 4:53 AM, Ozgur Karatas wrote:
>>>>  Hello,
>>>>
>>>>  I have error to use uuid and I think the functions should be used when 
>>>> -i'm eye-catching- "(* uuid)".
>>>>  I tested it.
>>>>
>>>>  Regards,
>>>>
>>>>  Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
>>>
>>>  NAK
>>>
>>>  This doesn't fix code style at all; there is no need and no
>>>  precedence for i.e. (*uuid) in function arguments in the xfs code,
>>>  and you have broken indentation in the loop within the function.
>>
>>  Perhaps better would be to convert the xfs uuid_t typedef
>>  to the include/uapi/linux/uuid.h appropriate struct and
>>  maybe use a comparison to NULL_UUID_
>>
>>>>  diff --git a/fs/xfs/uuid.c b/fs/xfs/uuid.c
>>  []
>>>>  @@ -33,7 +33,7 @@ typedef struct {
>>>>    * it just something that's needed for user-level file handles.
>>>>    */
>>>>   void
>>>>  -uuid_getnodeuniq(uuid_t *uuid, int fsid [2])
>>>>  +uuid_getnodeuniq(uuid_t (*uuid), int fsid [2])
>>
>>  And to amplify Eric's comment:
>>
>>  that bit is confusing as it makes uuid look
>>  like a function pointer.
>>
>>>>   {
>>>>   xfs_uu_t *uup = (xfs_uu_t *)uuid;
>>>>
>>>>  @@ -51,8 +51,8 @@ uuid_is_nil(uuid_t *uuid)
>>>>   if (uuid == NULL)
>>>>   return 0;
>>>>   /* implied check of version number here... */
>>>>  - for (i = 0; i < sizeof *uuid; i++)
>>>>  - if (*cp++) return 0; /* not nil */
>>>>  + for (i = 0; i < sizeof (*uuid); i++)
>>>>  + if (*cp++) return 0; /* not nil */
>>
>>  There shouldn't be a space after sizeof.
>
> and the "if" /should/ be indented under the for loop, because
> it is within the loop...
>
> I suppose simply:
>
> - for (i = 0; i < sizeof *uuid; i++)
> + for (i = 0; i < sizeof(*uuid); i++)
>
> would be fine on its own, though, because that is a bit
> unusual/inconsistent. I'll admit that I didn't spot
> that change as I scanned over the unnecessary & incorrect parts
> of the first patch. :)
>
> thanks,
> -Eric

Dear Eric;

Can you tell me the true code style? should use to (* uuid)? 
I'm learn to new and I'm newbies :)

Sorry,

Regards

Ozgur

Re: [PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

12.12.2016, 20:35, "Eric Sandeen" :
> On 12/12/16 12:14 PM, Joe Perches wrote:
>>  On Mon, 2016-12-12 at 07:49 -0600, Eric Sandeen wrote:
>>>  On 12/12/16 4:53 AM, Ozgur Karatas wrote:
>>>>  Hello,
>>>>
>>>>  I have error to use uuid and I think the functions should be used when 
>>>> -i'm eye-catching- "(* uuid)".
>>>>  I tested it.
>>>>
>>>>  Regards,
>>>>
>>>>  Signed-off-by: Ozgur Karatas 
>>>
>>>  NAK
>>>
>>>  This doesn't fix code style at all; there is no need and no
>>>  precedence for i.e. (*uuid) in function arguments in the xfs code,
>>>  and you have broken indentation in the loop within the function.
>>
>>  Perhaps better would be to convert the xfs uuid_t typedef
>>  to the include/uapi/linux/uuid.h appropriate struct and
>>  maybe use a comparison to NULL_UUID_
>>
>>>>  diff --git a/fs/xfs/uuid.c b/fs/xfs/uuid.c
>>  []
>>>>  @@ -33,7 +33,7 @@ typedef struct {
>>>>    * it just something that's needed for user-level file handles.
>>>>    */
>>>>   void
>>>>  -uuid_getnodeuniq(uuid_t *uuid, int fsid [2])
>>>>  +uuid_getnodeuniq(uuid_t (*uuid), int fsid [2])
>>
>>  And to amplify Eric's comment:
>>
>>  that bit is confusing as it makes uuid look
>>  like a function pointer.
>>
>>>>   {
>>>>   xfs_uu_t *uup = (xfs_uu_t *)uuid;
>>>>
>>>>  @@ -51,8 +51,8 @@ uuid_is_nil(uuid_t *uuid)
>>>>   if (uuid == NULL)
>>>>   return 0;
>>>>   /* implied check of version number here... */
>>>>  - for (i = 0; i < sizeof *uuid; i++)
>>>>  - if (*cp++) return 0; /* not nil */
>>>>  + for (i = 0; i < sizeof (*uuid); i++)
>>>>  + if (*cp++) return 0; /* not nil */
>>
>>  There shouldn't be a space after sizeof.
>
> and the "if" /should/ be indented under the for loop, because
> it is within the loop...
>
> I suppose simply:
>
> - for (i = 0; i < sizeof *uuid; i++)
> + for (i = 0; i < sizeof(*uuid); i++)
>
> would be fine on its own, though, because that is a bit
> unusual/inconsistent. I'll admit that I didn't spot
> that change as I scanned over the unnecessary & incorrect parts
> of the first patch. :)
>
> thanks,
> -Eric

Dear Eric;

Can you tell me the true code style? should use to (* uuid)? 
I'm learn to new and I'm newbies :)

Sorry,

Regards

Ozgur

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

[Ozgur Karatas]

12.12.2016, 20:18, "Leon Romanovsky" <l...@kernel.org>:
> On Mon, Dec 12, 2016 at 03:04:28PM +0200, Ozgur Karatas wrote:
>>  Dear Romanovsky;
>
> Please avoid top-posting in your replies.
> Thanks

Dear Leon; 
thanks for the information., I will pay attention.

>>  I'm trying to learn english and I apologize for my mistake words and 
>> phrases. So, I think the code when call to "sg_set_buf" and next time set 
>> memory and buffer. For example, isn't to call "WARN_ON" function, get a 
>> error to implicit declaration, right?
>>
>>  Because, you will use to "BUG_ON" get a error implicit declaration of 
>> functions.
>
> I'm not sure that I followed you. mem->offset is set by sg_set_buf from
> buf variable returned by dma_alloc_coherent(). HW needs to get very
> precise size of this buf, in multiple of pages and aligned to pages
> boundaries.

I have studied the following your coding and I guess that's the right patchs.
You are the very expert in this matter, thank you for the correct for me.

I learn to your style as an example.

Regards,

Ozgur Karatas

> See the patch inline which removes this BUG_ON in proper and safe way.
>
> From 7babe807affa2b27d51d3610afb75b693929ea1a Mon Sep 17 00:00:00 2001
> From: Leon Romanovsky <leo...@mellanox.com>
> Date: Mon, 12 Dec 2016 20:02:45 +0200
> Subject: [PATCH] net/mlx4: Remove BUG_ON from ICM allocation routine
>
> This patch removes BUG_ON() macro from mlx4_alloc_icm_coherent()
> by checking DMA address aligment in advance and performing proper
> folding in case of error.
>
> Fixes: 5b0bf5e25efe ("mlx4_core: Support ICM tables in coherent memory")
> Reported-by: Ozgur Karatas <okara...@member.fsf.org>
> Signed-off-by: Leon Romanovsky <leo...@mellanox.com>
> ---
>  drivers/net/ethernet/mellanox/mlx4/icm.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
> b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index 2a9dd46..e1f9e7c 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -118,8 +118,13 @@ static int mlx4_alloc_icm_coherent(struct device *dev, 
> struct scatterlist *mem,
>  if (!buf)
>  return -ENOMEM;
>
> + if (offset_in_page(buf)) {
> + dma_free_coherent(dev, PAGE_SIZE << order,
> + buf, sg_dma_address(mem));
> + return -ENOMEM;
> + }
> +
>  sg_set_buf(mem, buf, PAGE_SIZE << order);
> - BUG_ON(mem->offset);
>  sg_dma_len(mem) = PAGE_SIZE << order;
>  return 0;
>  }
> --
> 2.10.2

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

[Ozgur Karatas]

12.12.2016, 20:18, "Leon Romanovsky" :
> On Mon, Dec 12, 2016 at 03:04:28PM +0200, Ozgur Karatas wrote:
>>  Dear Romanovsky;
>
> Please avoid top-posting in your replies.
> Thanks

Dear Leon; 
thanks for the information., I will pay attention.

>>  I'm trying to learn english and I apologize for my mistake words and 
>> phrases. So, I think the code when call to "sg_set_buf" and next time set 
>> memory and buffer. For example, isn't to call "WARN_ON" function, get a 
>> error to implicit declaration, right?
>>
>>  Because, you will use to "BUG_ON" get a error implicit declaration of 
>> functions.
>
> I'm not sure that I followed you. mem->offset is set by sg_set_buf from
> buf variable returned by dma_alloc_coherent(). HW needs to get very
> precise size of this buf, in multiple of pages and aligned to pages
> boundaries.

I have studied the following your coding and I guess that's the right patchs.
You are the very expert in this matter, thank you for the correct for me.

I learn to your style as an example.

Regards,

Ozgur Karatas

> See the patch inline which removes this BUG_ON in proper and safe way.
>
> From 7babe807affa2b27d51d3610afb75b693929ea1a Mon Sep 17 00:00:00 2001
> From: Leon Romanovsky 
> Date: Mon, 12 Dec 2016 20:02:45 +0200
> Subject: [PATCH] net/mlx4: Remove BUG_ON from ICM allocation routine
>
> This patch removes BUG_ON() macro from mlx4_alloc_icm_coherent()
> by checking DMA address aligment in advance and performing proper
> folding in case of error.
>
> Fixes: 5b0bf5e25efe ("mlx4_core: Support ICM tables in coherent memory")
> Reported-by: Ozgur Karatas 
> Signed-off-by: Leon Romanovsky 
> ---
>  drivers/net/ethernet/mellanox/mlx4/icm.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
> b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index 2a9dd46..e1f9e7c 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -118,8 +118,13 @@ static int mlx4_alloc_icm_coherent(struct device *dev, 
> struct scatterlist *mem,
>  if (!buf)
>  return -ENOMEM;
>
> + if (offset_in_page(buf)) {
> + dma_free_coherent(dev, PAGE_SIZE << order,
> + buf, sg_dma_address(mem));
> + return -ENOMEM;
> + }
> +
>  sg_set_buf(mem, buf, PAGE_SIZE << order);
> - BUG_ON(mem->offset);
>  sg_dma_len(mem) = PAGE_SIZE << order;
>  return 0;
>  }
> --
> 2.10.2

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

[Ozgur Karatas]

Dear Romanovsky;

I'm trying to learn english and I apologize for my mistake words and phrases. 
So, I think the code when call to "sg_set_buf" and next time set memory and 
buffer. For example, isn't to call "WARN_ON" function, get a error to implicit 
declaration, right?

Because, you will use to "BUG_ON" get a error implicit declaration of functions.

sg_set_buf(mem, buf, PAGE_SIZE << order);
WARN_ON(mem->offset);

Thanks for information and learn to me.

Regards,

Ozgur Karatas

12.12.2016, 14:39, "Leon Romanovsky" <l...@kernel.org>:
> On Mon, Dec 12, 2016 at 12:58:59PM +0200, Ozgur Karatas wrote:
>>  Hello all,
>>  I think should be use to "WARN_ON" and checkpatch script give to error, I 
>> fixed and I think should don't use "BUG_ON".
>>  Regards,
>>
>>  Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
>
> NAK, Leon Romanovsky <leo...@mellanox.com>
>
> If we put aside commit message issue, which was pointed to you by Stefan, your
> proposed change is incorrect. By chnaging BUG_ONs to be WARN_ONs, you
> will left the driver in improper state.
>
> Thanks
>
>>  ---
>>  drivers/net/ethernet/mellanox/mlx4/icm.c | 4 ++--
>>
>>  diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
>> b/drivers/net/ethernet/mellanox/mlx4/icm.c
>>  index 2a9dd46..3fde535 100644
>>  --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
>>  +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
>>  @@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, 
>> struct scatterlist *mem,
>>   return -ENOMEM;
>>
>>   sg_set_buf(mem, buf, PAGE_SIZE << order);
>>  - BUG_ON(mem->offset);
>>  + WARN_ON(mem->offset);
>>   sg_dma_len(mem) = PAGE_SIZE << order;
>>   return 0;
>>   }
>>  @@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, 
>> int npages,
>>   int ret;
>>
>>   /* We use sg_set_buf for coherent allocs, which assumes low memory 
>> */
>>  - BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>>  + WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>>
>>   icm = kmalloc_node(sizeof(*icm),
>>  gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
>>  --
>>  2.1.4

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def

[Ozgur Karatas]

Dear Romanovsky;

I'm trying to learn english and I apologize for my mistake words and phrases. 
So, I think the code when call to "sg_set_buf" and next time set memory and 
buffer. For example, isn't to call "WARN_ON" function, get a error to implicit 
declaration, right?

Because, you will use to "BUG_ON" get a error implicit declaration of functions.

sg_set_buf(mem, buf, PAGE_SIZE << order);
WARN_ON(mem->offset);

Thanks for information and learn to me.

Regards,

Ozgur Karatas

12.12.2016, 14:39, "Leon Romanovsky" :
> On Mon, Dec 12, 2016 at 12:58:59PM +0200, Ozgur Karatas wrote:
>>  Hello all,
>>  I think should be use to "WARN_ON" and checkpatch script give to error, I 
>> fixed and I think should don't use "BUG_ON".
>>  Regards,
>>
>>  Signed-off-by: Ozgur Karatas 
>
> NAK, Leon Romanovsky 
>
> If we put aside commit message issue, which was pointed to you by Stefan, your
> proposed change is incorrect. By chnaging BUG_ONs to be WARN_ONs, you
> will left the driver in improper state.
>
> Thanks
>
>>  ---
>>  drivers/net/ethernet/mellanox/mlx4/icm.c | 4 ++--
>>
>>  diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
>> b/drivers/net/ethernet/mellanox/mlx4/icm.c
>>  index 2a9dd46..3fde535 100644
>>  --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
>>  +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
>>  @@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, 
>> struct scatterlist *mem,
>>   return -ENOMEM;
>>
>>   sg_set_buf(mem, buf, PAGE_SIZE << order);
>>  - BUG_ON(mem->offset);
>>  + WARN_ON(mem->offset);
>>   sg_dma_len(mem) = PAGE_SIZE << order;
>>   return 0;
>>   }
>>  @@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, 
>> int npages,
>>   int ret;
>>
>>   /* We use sg_set_buf for coherent allocs, which assumes low memory 
>> */
>>  - BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>>  + WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>>
>>   icm = kmalloc_node(sizeof(*icm),
>>  gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
>>  --
>>  2.1.4

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON

[Ozgur Karatas]

Dear Stefan;

I'm reading to Documentation/SubmittingPatches and I still apologized for 
misrepresentations my patches. 
I will add a next time good commit message and commit subjects.

Sorry,

Regards

Ozgur Karatas

12.12.2016, 13:20, "Stefan Schmidt" <ste...@osg.samsung.com>:
> Hello.
>
> On 12/12/16 11:58, Ozgur Karatas wrote:
>>  Hello all,
>>  I think should be use to "WARN_ON" and checkpatch script give to error, I 
>> fixed and I think should don't use "BUG_ON".
>>  Regards,
>>
>>  Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
>
> I pointed you already before to the Documentation how to prepare a
> commit subject and commit message. You just replied with that you are
> new to contributing patches. That is all fine and many people are new
> each release. Please take the time to read the provided and pointed out
> docs.
>
> If you keep ignoring such suggestions and docs I would think people will
> keep ignoring your patches.
>
> regards
> Stefan Schmidt

Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON

[Ozgur Karatas]

Dear Stefan;

I'm reading to Documentation/SubmittingPatches and I still apologized for 
misrepresentations my patches. 
I will add a next time good commit message and commit subjects.

Sorry,

Regards

Ozgur Karatas

12.12.2016, 13:20, "Stefan Schmidt" :
> Hello.
>
> On 12/12/16 11:58, Ozgur Karatas wrote:
>>  Hello all,
>>  I think should be use to "WARN_ON" and checkpatch script give to error, I 
>> fixed and I think should don't use "BUG_ON".
>>  Regards,
>>
>>  Signed-off-by: Ozgur Karatas 
>
> I pointed you already before to the Documentation how to prepare a
> commit subject and commit message. You just replied with that you are
> new to contributing patches. That is all fine and many people are new
> each release. Please take the time to read the provided and pointed out
> docs.
>
> If you keep ignoring such suggestions and docs I would think people will
> keep ignoring your patches.
>
> regards
> Stefan Schmidt

[PATCH 1/1] Fixed to BUG_ON to WARN_ON def

[Ozgur Karatas]

Hello all, 
I think should be use to "WARN_ON" and checkpatch script give to error, I fixed 
and I think  should don't use "BUG_ON".
Regards,

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
drivers/net/ethernet/mellanox/mlx4/icm.c |  4 ++--

diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
b/drivers/net/ethernet/mellanox/mlx4/icm.c
index 2a9dd46..3fde535 100644
--- a/drivers/net/ethernet/mellanox/mlx4/icm.c
+++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
@@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, 
struct scatterlist *mem,
return -ENOMEM;
 
sg_set_buf(mem, buf, PAGE_SIZE << order);
-   BUG_ON(mem->offset);
+   WARN_ON(mem->offset);
sg_dma_len(mem) = PAGE_SIZE << order;
return 0;
 }
@@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int 
npages,
int ret;
 
/* We use sg_set_buf for coherent allocs, which assumes low memory */
-   BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
+   WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
 
icm = kmalloc_node(sizeof(*icm),
   gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
-- 
2.1.4

[PATCH 1/1] Fixed to BUG_ON to WARN_ON def

[Ozgur Karatas]

Hello all, 
I think should be use to "WARN_ON" and checkpatch script give to error, I fixed 
and I think  should don't use "BUG_ON".
Regards,

Signed-off-by: Ozgur Karatas 
---
drivers/net/ethernet/mellanox/mlx4/icm.c |  4 ++--

diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
b/drivers/net/ethernet/mellanox/mlx4/icm.c
index 2a9dd46..3fde535 100644
--- a/drivers/net/ethernet/mellanox/mlx4/icm.c
+++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
@@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, 
struct scatterlist *mem,
return -ENOMEM;
 
sg_set_buf(mem, buf, PAGE_SIZE << order);
-   BUG_ON(mem->offset);
+   WARN_ON(mem->offset);
sg_dma_len(mem) = PAGE_SIZE << order;
return 0;
 }
@@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int 
npages,
int ret;
 
/* We use sg_set_buf for coherent allocs, which assumes low memory */
-   BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
+   WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
 
icm = kmalloc_node(sizeof(*icm),
   gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
-- 
2.1.4

[PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

Hello,

I have error to use uuid and I think the functions should be used when -i'm 
eye-catching- "(* uuid)".
I tested it.

Regards,

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
diff --git a/fs/xfs/uuid.c b/fs/xfs/uuid.c
index b83f76b..cd8bc8e 100644
--- a/fs/xfs/uuid.c
+++ b/fs/xfs/uuid.c
@@ -33,7 +33,7 @@ typedef struct {
  * it just something that's needed for user-level file handles.
  */
 void
-uuid_getnodeuniq(uuid_t *uuid, int fsid [2])
+uuid_getnodeuniq(uuid_t (*uuid), int fsid [2])
 {
xfs_uu_t *uup = (xfs_uu_t *)uuid;
 
@@ -51,8 +51,8 @@ uuid_is_nil(uuid_t *uuid)
if (uuid == NULL)
return 0;
/* implied check of version number here... */
-   for (i = 0; i < sizeof *uuid; i++)
-   if (*cp++) return 0;/* not nil */
+   for (i = 0; i < sizeof (*uuid); i++) 
+   if (*cp++) return 0;/* not nil */
return 1;   /* is nil */
 }

-- 
2.1.4

[PATCH 1/1] Fixed to codestyle

[Ozgur Karatas]

Hello,

I have error to use uuid and I think the functions should be used when -i'm 
eye-catching- "(* uuid)".
I tested it.

Regards,

Signed-off-by: Ozgur Karatas 
---
diff --git a/fs/xfs/uuid.c b/fs/xfs/uuid.c
index b83f76b..cd8bc8e 100644
--- a/fs/xfs/uuid.c
+++ b/fs/xfs/uuid.c
@@ -33,7 +33,7 @@ typedef struct {
  * it just something that's needed for user-level file handles.
  */
 void
-uuid_getnodeuniq(uuid_t *uuid, int fsid [2])
+uuid_getnodeuniq(uuid_t (*uuid), int fsid [2])
 {
xfs_uu_t *uup = (xfs_uu_t *)uuid;
 
@@ -51,8 +51,8 @@ uuid_is_nil(uuid_t *uuid)
if (uuid == NULL)
return 0;
/* implied check of version number here... */
-   for (i = 0; i < sizeof *uuid; i++)
-   if (*cp++) return 0;/* not nil */
+   for (i = 0; i < sizeof (*uuid); i++) 
+   if (*cp++) return 0;/* not nil */
return 1;   /* is nil */
 }

-- 
2.1.4

[PATCH 1/1] Fixed checkpatch error to mmu.c

[Ozgur Karatas]

Hello all,

I tested to mmu.c and I have fixed to some errors.

mmu.c:510: ERROR: "(foo*)" should be "(foo *)"

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
arch/arm/kvm/mmu.c   |  2 +-

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index a5265ed..a83cf47 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -507,7 +507,7 @@ void free_hyp_pgds(void)
unmap_hyp_range(hyp_pgd, hyp_idmap_start, PAGE_SIZE);
for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += 
PGDIR_SIZE)
unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);
-   for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr 
+= PGDIR_SIZE)
+   for (addr = VMALLOC_START; is_vmalloc_addr((void *)addr); addr 
+= PGDIR_SIZE)
unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);

-- 
2.1.4

[PATCH 1/1] Fixed checkpatch error to mmu.c

[Ozgur Karatas]

Hello all,

I tested to mmu.c and I have fixed to some errors.

mmu.c:510: ERROR: "(foo*)" should be "(foo *)"

Signed-off-by: Ozgur Karatas 
---
arch/arm/kvm/mmu.c   |  2 +-

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index a5265ed..a83cf47 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -507,7 +507,7 @@ void free_hyp_pgds(void)
unmap_hyp_range(hyp_pgd, hyp_idmap_start, PAGE_SIZE);
for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += 
PGDIR_SIZE)
unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);
-   for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr 
+= PGDIR_SIZE)
+   for (addr = VMALLOC_START; is_vmalloc_addr((void *)addr); addr 
+= PGDIR_SIZE)
unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);

-- 
2.1.4

[PATCH 1/1] Fixed to checkpatch errors to usbtmc.c

[Ozgur Karatas]

Hello all,

I will solve a checkpatch.pl script errors.

drivers/usb/class/usbtmc.c:719: ERROR: else should follow close brace '}'
drivers/usb/class/usbtmc.c:735: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:735: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:735: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:746: ERROR: else should follow close brace '}'
drivers/usb/class/usbtmc.c:752: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:752: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:1403: ERROR: space required before the open 
parenthesis '('
total: 8 errors, 25 warnings, 1558 lines checked

Regards,

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 drivers/usb/class/usbtmc.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index a6c1fae..3b29871 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -715,8 +715,7 @@ static ssize_t usbtmc_read(struct file *filp, char __user 
*buf,
/* Remove padding if it exists */
if (actual > remaining)
actual = remaining;
-   }
-   else {
+   } else {
if (this_part > n_characters)
this_part = n_characters;
/* Remove padding if it exists */
@@ -732,7 +731,7 @@ static ssize_t usbtmc_read(struct file *filp, char __user 
*buf,
if ((buffer[8] & 0x01) && (actual >= n_characters))
remaining = 0;
 
-   dev_dbg(dev, "Bulk-IN header: remaining(%zu), buf(%p), 
buffer(%p) done(%zu)\n", remaining,buf,buffer,done);
+   dev_dbg(dev, "Bulk-IN header: remaining(%zu), buf(%p), 
buffer(%p) done(%zu)\n", remaining, buf, buffer, done);
 
 
/* Copy buffer to user space */
@@ -742,14 +741,13 @@ static ssize_t usbtmc_read(struct file *filp, char __user 
*buf,
goto exit;
}
done += actual;
-   }
-   else  {
+   } else  {
if (actual > remaining)
actual = remaining;
 
remaining -= actual;
 
-   dev_dbg(dev, "Bulk-IN header cont: actual(%u), 
done(%zu), remaining(%zu), buf(%p), buffer(%p)\n", actual, done, 
remaining,buf,buffer);
+   dev_dbg(dev, "Bulk-IN header cont: actual(%u), 
done(%zu), remaining(%zu), buf(%p), buffer(%p)\n", actual, done, remaining, 
buf, buffer);
 
/* Copy buffer to user space */
if (copy_to_user(buf + done, buffer, actual)) {
@@ -1400,7 +1398,7 @@ static int usbtmc_probe(struct usb_interface *intf,
dev_dbg(>dev, "Trying to find if device Vendor 0x%04X Product 
0x%04X has the RIGOL quirk\n",
le16_to_cpu(data->usb_dev->descriptor.idVendor),
le16_to_cpu(data->usb_dev->descriptor.idProduct));
-   for(n = 0; usbtmc_id_quirk[n].idVendor > 0; n++) {
+   for (n = 0; usbtmc_id_quirk[n].idVendor > 0; n++) {
if ((usbtmc_id_quirk[n].idVendor == 
le16_to_cpu(data->usb_dev->descriptor.idVendor)) &&
(usbtmc_id_quirk[n].idProduct == 
le16_to_cpu(data->usb_dev->descriptor.idProduct))) {
dev_dbg(>dev, "Setting this device as having the 
RIGOL quirk\n");
-- 
2.1.4

[PATCH 1/1] Fixed to checkpatch errors to usbtmc.c

[Ozgur Karatas]

Hello all,

I will solve a checkpatch.pl script errors.

drivers/usb/class/usbtmc.c:719: ERROR: else should follow close brace '}'
drivers/usb/class/usbtmc.c:735: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:735: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:735: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:746: ERROR: else should follow close brace '}'
drivers/usb/class/usbtmc.c:752: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:752: ERROR: space required after that ',' (ctx:VxV)
drivers/usb/class/usbtmc.c:1403: ERROR: space required before the open 
parenthesis '('
total: 8 errors, 25 warnings, 1558 lines checked

Regards,

Signed-off-by: Ozgur Karatas 
---
 drivers/usb/class/usbtmc.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index a6c1fae..3b29871 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -715,8 +715,7 @@ static ssize_t usbtmc_read(struct file *filp, char __user 
*buf,
/* Remove padding if it exists */
if (actual > remaining)
actual = remaining;
-   }
-   else {
+   } else {
if (this_part > n_characters)
this_part = n_characters;
/* Remove padding if it exists */
@@ -732,7 +731,7 @@ static ssize_t usbtmc_read(struct file *filp, char __user 
*buf,
if ((buffer[8] & 0x01) && (actual >= n_characters))
remaining = 0;
 
-   dev_dbg(dev, "Bulk-IN header: remaining(%zu), buf(%p), 
buffer(%p) done(%zu)\n", remaining,buf,buffer,done);
+   dev_dbg(dev, "Bulk-IN header: remaining(%zu), buf(%p), 
buffer(%p) done(%zu)\n", remaining, buf, buffer, done);
 
 
/* Copy buffer to user space */
@@ -742,14 +741,13 @@ static ssize_t usbtmc_read(struct file *filp, char __user 
*buf,
goto exit;
}
done += actual;
-   }
-   else  {
+   } else  {
if (actual > remaining)
actual = remaining;
 
remaining -= actual;
 
-   dev_dbg(dev, "Bulk-IN header cont: actual(%u), 
done(%zu), remaining(%zu), buf(%p), buffer(%p)\n", actual, done, 
remaining,buf,buffer);
+   dev_dbg(dev, "Bulk-IN header cont: actual(%u), 
done(%zu), remaining(%zu), buf(%p), buffer(%p)\n", actual, done, remaining, 
buf, buffer);
 
/* Copy buffer to user space */
if (copy_to_user(buf + done, buffer, actual)) {
@@ -1400,7 +1398,7 @@ static int usbtmc_probe(struct usb_interface *intf,
dev_dbg(>dev, "Trying to find if device Vendor 0x%04X Product 
0x%04X has the RIGOL quirk\n",
le16_to_cpu(data->usb_dev->descriptor.idVendor),
le16_to_cpu(data->usb_dev->descriptor.idProduct));
-   for(n = 0; usbtmc_id_quirk[n].idVendor > 0; n++) {
+   for (n = 0; usbtmc_id_quirk[n].idVendor > 0; n++) {
if ((usbtmc_id_quirk[n].idVendor == 
le16_to_cpu(data->usb_dev->descriptor.idVendor)) &&
(usbtmc_id_quirk[n].idProduct == 
le16_to_cpu(data->usb_dev->descriptor.idProduct))) {
dev_dbg(>dev, "Setting this device as having the 
RIGOL quirk\n");
-- 
2.1.4

[PATCH 130/130] Fixed to checkpatch errors.

[Ozgur Karatas]

Hello,

Fixed to checkpatch errors.

ERROR: net/wireless/util.c:1787: ERROR: that open brace { should be on the 
previous line
ERROR: net/wireless/util.c:1792: ERROR: that open brace { should be on the 
previous line

Signed-off-by: Ozgur Karatas <okara...@member.fsf.org>
---
 net/wireless/util.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 659b507..f4ac755 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1783,11 +1783,13 @@ EXPORT_SYMBOL(cfg80211_free_nan_func);
 
 /* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
 /* Ethernet-II snap header (RFC1042 for most EtherTypes) */
-const unsigned char rfc1042_header[] __aligned(2) =
-   { 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 };
+const unsigned char rfc1042_header[] __aligned(2) = {
+   0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00
+};
 EXPORT_SYMBOL(rfc1042_header);
 
 /* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */
-const unsigned char bridge_tunnel_header[] __aligned(2) =
-   { 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 };
+const unsigned char bridge_tunnel_header[] __aligned(2) = {
+   0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8
+};
 EXPORT_SYMBOL(bridge_tunnel_header);
-- 
2.1.4

[PATCH 130/130] Fixed to checkpatch errors.

[Ozgur Karatas]

Hello,

Fixed to checkpatch errors.

ERROR: net/wireless/util.c:1787: ERROR: that open brace { should be on the 
previous line
ERROR: net/wireless/util.c:1792: ERROR: that open brace { should be on the 
previous line

Signed-off-by: Ozgur Karatas 
---
 net/wireless/util.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 659b507..f4ac755 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1783,11 +1783,13 @@ EXPORT_SYMBOL(cfg80211_free_nan_func);
 
 /* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
 /* Ethernet-II snap header (RFC1042 for most EtherTypes) */
-const unsigned char rfc1042_header[] __aligned(2) =
-   { 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 };
+const unsigned char rfc1042_header[] __aligned(2) = {
+   0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00
+};
 EXPORT_SYMBOL(rfc1042_header);
 
 /* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */
-const unsigned char bridge_tunnel_header[] __aligned(2) =
-   { 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 };
+const unsigned char bridge_tunnel_header[] __aligned(2) = {
+   0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8
+};
 EXPORT_SYMBOL(bridge_tunnel_header);
-- 
2.1.4

[PATCH] Fixed to checkpatch.pl errors to vlan_dev.c

[Ozgur Karatas]

Hello all,

I will solve a checkpatch errors.

Signed-off-by: Ozgur Karatas <oz...@member.fsf.org>

---
 net/8021q/vlan_dev.c   |   2 +-
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index fbfacd5..2edb495 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -738,7 +738,7 @@ static int vlan_dev_netpoll_setup(struct net_device *dev, 
struct netpoll_info *n

 static void vlan_dev_netpoll_cleanup(struct net_device *dev)
 {
-   struct vlan_dev_priv *vlan= vlan_dev_priv(dev);
+   struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
struct netpoll *netpoll = vlan->netpoll;

if (!netpoll)

[PATCH] Fixed to checkpatch.pl errors to vlan_dev.c

[Ozgur Karatas]

Hello all,

I will solve a checkpatch errors.

Signed-off-by: Ozgur Karatas 

---
 net/8021q/vlan_dev.c   |   2 +-
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index fbfacd5..2edb495 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -738,7 +738,7 @@ static int vlan_dev_netpoll_setup(struct net_device *dev, 
struct netpoll_info *n

 static void vlan_dev_netpoll_cleanup(struct net_device *dev)
 {
-   struct vlan_dev_priv *vlan= vlan_dev_priv(dev);
+   struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
struct netpoll *netpoll = vlan->netpoll;

if (!netpoll)