* Re: selftests/bpf doesn't compile
From: Daniel Borkmann @ 2017-09-15 18:48 UTC (permalink / raw)
To: Alexei Starovoitov, Edward Cree
Cc: Shuah Khan, Thomas Meyer, linux-kernel, linux-kselftest,
Shuah Khan, Networking
In-Reply-To: <59BC1AAC.3040401@iogearbox.net>
On 09/15/2017 08:23 PM, Daniel Borkmann wrote:
> On 09/15/2017 08:07 PM, Alexei Starovoitov wrote:
>> On Fri, Sep 15, 2017 at 05:58:40PM +0100, Edward Cree wrote:
>>> On 15/09/17 17:02, Alexei Starovoitov wrote:
>>>> On Thu, Sep 14, 2017 at 09:33:48AM -0600, Shuah Khan wrote:
>>>>> Is bpf test intended to be run in kselftest run? The clang dependency might
>>>>> not be met on majority of the systems. Is this a hard dependency??
>>>> It is a hard dependency and clang should be present on majority of the systems.
>>> I think this is the wrong approach. Making kselftest hard-require clang doesn't
>>> mean that the bpf tests will be run more often, it means that the rest of the
>>> kselftests will be run less often. clang is quite big (when I tried to install
>>> it on one of my test servers, I didn't have enough disk space & had to go on a
>>> clear-out of unused packages), and most people aren't interested in the bpf
>>> subsystem specifically; they would rather be able to skip those tests.
>>> I feel that as long as they know they are skipping some tests (so e.g. they
>>> won't consider it a sufficient test of a kselftest refactor), that's fine.
>>> It's not even as though all of the bpf tests require clang; the (smaller) tests
>>> written directly in raw eBPF instructions could still be run on such a system.
>>> So I think we should attempt to run as much as possible but accept that clang
>>> may not be available and have an option to skip some tests in that case.
>>
>> imo the value of selftests/bpf is twofold:
>> 1. it helps bpf developers avoid regressions
>> 2. as part of continuous integration it helps to catch bpf regressions
>> that were somehow caused by changes in other parts of the kernel
>>
>> If a developer didn't bother to satisfy all bpf tests dependencies
>> (which includes clang) and ran all tests before sending a patch,
>> I don't want to see such patches. It just wastes maintainers time
>> to review code and spot bugs that could have been caught by tests.
>> Collectively we invested years of work into these tests and
>> developers better take advantage of it by running all.
>
> +1
>
>> If a CI server didn't satisfy all bpf test dependencies,
>> I don't want such CI setup to be running and reporting results,
>> since it will give false sense of test coverage.
>> Test failures due to missing dependencies are hard failures.
>> We cannot skip them.
>
> +1
Btw, on that note, the folks from zero-day bot run the BPF kselftests
for a while now just fine and they do run them together with clang,
so they have the full, proper coverage how it should be. It's not
how it used to be in the early days, you can just go and install
llvm/clang package on all the major distros today and you get the
bpf target by default enabled already.
>> I'd like generic XDP tests to be added to selftests/bpf which
>> would mean that the latest iproute2 will become a hard dependency
>> and bpf developers and CI host owners would need to upgrade
>> their iproute2.
>> The tests either pass or fail. Skipping them due to missing
>> dependencies is the same as fail and in that sense I don't want
>> to change selftests/bpf/Makefile to make it skip clang.
>
> I fully agree that for the BPF selftests it is very desirable
> to not only test the verifier with couple of BPF insn snippets,
> but to actually load and run programs that more closely resemble
> real world programs. For more complex interactions these snippets
> are just limited, think of tail calls, testing perf event output
> helper, etc, which would all require to write these tests with
> restricted C when we add them (unless we want to make writing
> these tests a real pain ;) in which case no-one will bother to
> write tests at all for them). Mid to long term I would definitely
> like to see more programs in BPF selftests (e.g. moved over from
> samples/bpf/) to increase the test coverage.
^ permalink raw reply
* Re: [REGRESSION] Warning in tcp_fastretrans_alert() of net/ipv4/tcp_input.c
From: Oleksandr Natalenko @ 2017-09-15 19:04 UTC (permalink / raw)
To: Neal Cardwell
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Netdev,
Yuchung Cheng
In-Reply-To: <CADVnQymkqE+mt4OwtkL1ddpRbqJYPH8CJ0JhNn6ML9YPJdCJxA@mail.gmail.com>
Hello.
With net.ipv4.tcp_fack set to 0 the warning still appears:
===
» sysctl net.ipv4.tcp_fack
net.ipv4.tcp_fack = 0
» LC_TIME=C dmesg -T | grep WARNING
[Fri Sep 15 20:40:30 2017] WARNING: CPU: 1 PID: 711 at net/ipv4/tcp_input.c:
2826 tcp_fastretrans_alert+0x7c8/0x990
[Fri Sep 15 20:40:30 2017] WARNING: CPU: 0 PID: 711 at net/ipv4/tcp_input.c:
2826 tcp_fastretrans_alert+0x7c8/0x990
[Fri Sep 15 20:48:37 2017] WARNING: CPU: 1 PID: 711 at net/ipv4/tcp_input.c:
2826 tcp_fastretrans_alert+0x7c8/0x990
[Fri Sep 15 20:48:55 2017] WARNING: CPU: 0 PID: 711 at net/ipv4/tcp_input.c:
2826 tcp_fastretrans_alert+0x7c8/0x990
» ps -up 711
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 711 4.3 0.0 0 0 ? S 18:12 7:23 [irq/123-
enp3s0]
===
Any suggestions?
On pátek 15. září 2017 16:03:00 CEST Neal Cardwell wrote:
> Thanks for testing that. That is a very useful data point.
>
> I was able to cook up a packetdrill test that could put the connection
> in CA_Disorder with retransmitted packets out, but not in CA_Open. So
> we do not yet have a test case to reproduce this.
>
> We do not see this warning on our fleet at Google. One significant
> difference I see between our environment and yours is that it seems
> you run with FACK enabled:
>
> net.ipv4.tcp_fack = 1
>
> Note that FACK was disabled by default (since it was replaced by RACK)
> between kernel v4.10 and v4.11. And this is exactly the time when this
> bug started manifesting itself for you and some others, but not our
> fleet. So my new working hypothesis would be that this warning is due
> to a behavior that only shows up in kernels >=4.11 when FACK is
> enabled.
>
> Would you be able to disable FACK ("sysctl net.ipv4.tcp_fack=0" at
> boot, or net.ipv4.tcp_fack=0 in /etc/sysctl.conf, or equivalent),
> reboot, and test the kernel for a few days to see if the warning still
> pops up?
>
> thanks,
> neal
>
> [ps: apologies for the previous, mis-formatted post...]
^ permalink raw reply
* Re: Regression in throughput between kvm guests over virtual bridge
From: Matthew Rosato @ 2017-09-15 19:19 UTC (permalink / raw)
To: Jason Wang, netdev; +Cc: davem, mst
In-Reply-To: <15abafa1-6d58-cd85-668a-bf361a296f52@redhat.com>
> It looks like vhost is slowed down for some reason which leads to more
> idle time on 4.13+VHOST_RX_BATCH=1. Appreciated if you can collect the
> perf.diff on host, one for rx and one for tx.
>
perf data below for the associated vhost threads, baseline=4.12,
delta1=4.13, delta2=4.13+VHOST_RX_BATCH=1
Client vhost:
60.12% -11.11% -12.34% [kernel.vmlinux] [k] raw_copy_from_user
13.76% -1.28% -0.74% [kernel.vmlinux] [k] get_page_from_freelist
2.00% +3.69% +3.54% [kernel.vmlinux] [k] __wake_up_sync_key
1.19% +0.60% +0.66% [kernel.vmlinux] [k] __alloc_pages_nodemask
1.12% +0.76% +0.86% [kernel.vmlinux] [k] copy_page_from_iter
1.09% +0.28% +0.35% [vhost] [k] vhost_get_vq_desc
1.07% +0.31% +0.26% [kernel.vmlinux] [k] alloc_skb_with_frags
0.94% +0.42% +0.65% [kernel.vmlinux] [k] alloc_pages_current
0.91% -0.19% -0.18% [kernel.vmlinux] [k] memcpy
0.88% +0.26% +0.30% [kernel.vmlinux] [k] __next_zones_zonelist
0.85% +0.05% +0.12% [kernel.vmlinux] [k] iov_iter_advance
0.79% +0.09% +0.19% [vhost] [k] __vhost_add_used_n
0.74% [kernel.vmlinux] [k] get_task_policy.part.7
0.74% -0.01% -0.05% [kernel.vmlinux] [k] tun_net_xmit
0.60% +0.17% +0.33% [kernel.vmlinux] [k] policy_nodemask
0.58% -0.15% -0.12% [ebtables] [k] ebt_do_table
0.52% -0.25% -0.22% [kernel.vmlinux] [k] __alloc_skb
...
0.42% +0.58% +0.59% [kernel.vmlinux] [k] eventfd_signal
...
0.32% +0.96% +0.93% [kernel.vmlinux] [k] finish_task_switch
...
+1.50% +1.16% [kernel.vmlinux] [k] get_task_policy.part.9
+0.40% +0.42% [kernel.vmlinux] [k] __skb_get_hash_symmetr
+0.39% +0.40% [kernel.vmlinux] [k] _copy_from_iter_full
+0.24% +0.23% [vhost_net] [k] vhost_net_buf_peek
Server vhost:
61.93% -10.72% -10.91% [kernel.vmlinux] [k] raw_copy_to_user
9.25% +0.47% +0.86% [kernel.vmlinux] [k] free_hot_cold_page
5.16% +1.41% +1.57% [vhost] [k] vhost_get_vq_desc
5.12% -3.81% -3.78% [kernel.vmlinux] [k] skb_release_data
3.30% +0.42% +0.55% [kernel.vmlinux] [k] raw_copy_from_user
1.29% +2.20% +2.28% [kernel.vmlinux] [k] copy_page_to_iter
1.24% +1.65% +0.45% [vhost_net] [k] handle_rx
1.08% +3.03% +2.85% [kernel.vmlinux] [k] __wake_up_sync_key
0.96% +0.70% +1.10% [vhost] [k] translate_desc
0.69% -0.20% -0.22% [kernel.vmlinux] [k] tun_do_read.part.10
0.69% [kernel.vmlinux] [k] tun_peek_len
0.67% +0.75% +0.78% [kernel.vmlinux] [k] eventfd_signal
0.52% +0.96% +0.98% [kernel.vmlinux] [k] finish_task_switch
0.50% +0.05% +0.09% [vhost] [k] vhost_add_used_n
...
+0.63% +0.58% [vhost_net] [k] vhost_net_buf_peek
+0.32% +0.32% [kernel.vmlinux] [k] _copy_to_iter
+0.19% +0.19% [kernel.vmlinux] [k] __skb_get_hash_symmetr
+0.11% +0.21% [vhost] [k] vhost_umem_interval_tr
^ permalink raw reply
* Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13
From: Larry Finger @ 2017-09-15 19:21 UTC (permalink / raw)
To: Zwindl
Cc: linux-wireless@vger.kernel.org, chaoming_li@realsil.com.cn,
kvalo@codeaurora.org, pkshih@realtek.com, johannes.berg@intel.com,
gregkh@linuxfoundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <x1duse6v9TTP8Ta7rsTLlZ8DK0Ej7qq9iapef18K0eYSodmCBmfI_mX3c-3ocbPiGzEgV9weOh25dKWSbU5nIetYkfmmUxaxRpUdYFffRZA=@protonmail.com>
On 09/15/2017 12:12 PM, Zwindl wrote:
> Thanks for your patient and advice, I'll keep that in mind.
> I do want help, and I got 1 day to build the system, but I can't recall how to
> compile it, The last time I compile kernel is 2013, so, maybe I'll ask you so
> many stupid questions during the build time.
> ZWindL
Building a new kernel is not difficult. In an average week, I make at least 10
new kernels. Many of them are done on slow machines that take many hours. At
least, your i5 CPU should do it in less that one hour.
Step 1: Download the kernel sources using
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
If your system complains that the git command is unknown, then you will need to
install it with your package manager (pacman?).
Step 2: "cd linux" and copy the latest /boot/config-..... to the linux source
directory as ".config". Edit .config, find the line that says
"# CONFIG_LOCALVERSION_AUTO is not set", and change the line to read
"CONFIG_LOCALVERSION_AUTO=y".
Step 3: Build and install the latest version using
make -j9
sudo make modules_install install
You will need to answer some configuration questions at the start of the first
make line. Answer with the default value, i.e. just use an ENTER. When the build
is complete, reboot. Grub should show an entry for something like
v4.13-12084-ged43e4d190d0. The numbers after the 4.13 will likely be different,
but the form will match. Check that the new kernel still has the fault. If not,
it has been fixed and we do not need to find it.
It the problem is still in the latest version of the kernel, then we start the
bisection with the following:
git bisect start
git bisect bad v4.13
git bisect good v4.12
At this point, git will report the number of revisions to test, the likely
number of tries, and the SHA hash for the new kernel. Record the first 7 digits
of the hash, and repeat the make commands above. After the build is complete,
reboot into the kernel with the hash in the version name and test. Then enter
the command "git bisect xxx", where xxx is good or bad depending on the test. A
new trial will be generated by bisecting the appropriate half of the commits.
Record its hash and redo the build. Repeat until git tells you the bad commit.
This process will generate a number of kernels that will take quite a bit of
disk space. If you run short, you can delete kernels that have already been
tested from /boot. You should also delete the corresponding modules from
/lib/modules.
Good luck,
Larry
^ permalink raw reply
* [PATCH] Staging: irda: Don't use assignment inside if statement
From: Srishti Sharma @ 2017-09-15 19:33 UTC (permalink / raw)
To: samuel
Cc: gregkh, netdev, devel, linux-kernel, outreachy-kernel,
Srishti Sharma
Write assignment statement outside the if statement. Done using
the following semantic patch by coccinelle.
@@
identifier E;
expression F;
statement S;
@@
-if((E = F))
+E = F
+if(E)
S
Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
---
drivers/staging/irda/drivers/irda-usb.c | 4 ++--
drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
drivers/staging/irda/net/irqueue.c | 3 ++-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
index 723e49b..82bfc05 100644
--- a/drivers/staging/irda/drivers/irda-usb.c
+++ b/drivers/staging/irda/drivers/irda-usb.c
@@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
urb->transfer_flags = 0;
/* Irq disabled -> GFP_ATOMIC */
- if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret)
net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
- }
}
/*------------------------------------------------------------------*/
diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
index c3f0b25..2b674d5 100644
--- a/drivers/staging/irda/drivers/mcs7780.c
+++ b/drivers/staging/irda/drivers/mcs7780.c
@@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
if (mcs->new_speed <= 115200) {
rval &= ~MCS_FIR;
- if ((rst = (mcs->speed > 115200)))
+ rst = (mcs->speed > 115200);
+ if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
} else if (mcs->new_speed <= 1152000) {
rval &= ~MCS_FIR;
- if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
+ rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
+ if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
} else {
rval |= MCS_FIR;
- if ((rst = (mcs->speed != 4000000)))
+ rst = (mcs->speed != 4000000);
+ if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
}
diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
index 160dc89..5aab072 100644
--- a/drivers/staging/irda/net/irqueue.c
+++ b/drivers/staging/irda/net/irqueue.c
@@ -217,7 +217,8 @@ static __u32 hash( const char* name)
while(*name) {
h = (h<<4) + *name++;
- if ((g = (h & 0xf0000000)))
+ g = (h & 0xf0000000);
+ if (g)
h ^=g>>24;
h &=~g;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] Staging: irda: Don't use assignment inside if statement
From: Srishti Sharma @ 2017-09-15 19:36 UTC (permalink / raw)
To: samuel
Cc: devel, Greg KH, Linux kernel mailing list, outreachy-kernel,
Srishti Sharma, netdev
In-Reply-To: <1505504036-21807-1-git-send-email-srishtishar@gmail.com>
On Sat, Sep 16, 2017 at 1:03 AM, Srishti Sharma <srishtishar@gmail.com> wrote:
> Write assignment statement outside the if statement. Done using
> the following semantic patch by coccinelle.
>
> @@
> identifier E;
> expression F;
> statement S;
> @@
>
> -if((E = F))
> +E = F
> +if(E)
> S
>
> Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
> ---
> drivers/staging/irda/drivers/irda-usb.c | 4 ++--
> drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
> drivers/staging/irda/net/irqueue.c | 3 ++-
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
> index 723e49b..82bfc05 100644
> --- a/drivers/staging/irda/drivers/irda-usb.c
> +++ b/drivers/staging/irda/drivers/irda-usb.c
> @@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
> urb->transfer_flags = 0;
>
> /* Irq disabled -> GFP_ATOMIC */
> - if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
> + ret = usb_submit_urb(urb, GFP_ATOMIC);
> + if (ret)
> net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
> - }
> }
>
> /*------------------------------------------------------------------*/
> diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
> index c3f0b25..2b674d5 100644
> --- a/drivers/staging/irda/drivers/mcs7780.c
> +++ b/drivers/staging/irda/drivers/mcs7780.c
> @@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
> if (mcs->new_speed <= 115200) {
> rval &= ~MCS_FIR;
>
> - if ((rst = (mcs->speed > 115200)))
> + rst = (mcs->speed > 115200);
> + if (rst)
> mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
>
> } else if (mcs->new_speed <= 1152000) {
> rval &= ~MCS_FIR;
>
> - if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
> + rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
> + if (rst)
> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>
> } else {
> rval |= MCS_FIR;
>
> - if ((rst = (mcs->speed != 4000000)))
> + rst = (mcs->speed != 4000000);
> + if (rst)
> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>
> }
> diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
> index 160dc89..5aab072 100644
> --- a/drivers/staging/irda/net/irqueue.c
> +++ b/drivers/staging/irda/net/irqueue.c
> @@ -217,7 +217,8 @@ static __u32 hash( const char* name)
>
> while(*name) {
> h = (h<<4) + *name++;
> - if ((g = (h & 0xf0000000)))
> + g = (h & 0xf0000000);
> + if (g)
> h ^=g>>24;
> h &=~g;
> }
> --
> 2.7.4
>
There is a mistake here please ignore this patch , I'll send a v2 , I
forgot to put a semicolon in the semantic patch .
Regards,
Srishti
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH] Staging: irda: Don't use assignment inside if statement
From: Julia Lawall @ 2017-09-15 19:38 UTC (permalink / raw)
To: Srishti Sharma
Cc: samuel, gregkh, netdev, devel, linux-kernel, outreachy-kernel
In-Reply-To: <1505504036-21807-1-git-send-email-srishtishar@gmail.com>
On Sat, 16 Sep 2017, Srishti Sharma wrote:
> Write assignment statement outside the if statement. Done using
> the following semantic patch by coccinelle.
>
> @@
> identifier E;
> expression F;
> statement S;
> @@
>
> -if((E = F))
> +E = F
The line above would need to end in a ;
This ends up with a lot of assignments with () around the right hand side.
Maybe you could make a series removing them afterwards.
julia
> +if(E)
> S
>
> Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
> ---
> drivers/staging/irda/drivers/irda-usb.c | 4 ++--
> drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
> drivers/staging/irda/net/irqueue.c | 3 ++-
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
> index 723e49b..82bfc05 100644
> --- a/drivers/staging/irda/drivers/irda-usb.c
> +++ b/drivers/staging/irda/drivers/irda-usb.c
> @@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
> urb->transfer_flags = 0;
>
> /* Irq disabled -> GFP_ATOMIC */
> - if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
> + ret = usb_submit_urb(urb, GFP_ATOMIC);
> + if (ret)
> net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
> - }
> }
>
> /*------------------------------------------------------------------*/
> diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
> index c3f0b25..2b674d5 100644
> --- a/drivers/staging/irda/drivers/mcs7780.c
> +++ b/drivers/staging/irda/drivers/mcs7780.c
> @@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
> if (mcs->new_speed <= 115200) {
> rval &= ~MCS_FIR;
>
> - if ((rst = (mcs->speed > 115200)))
> + rst = (mcs->speed > 115200);
> + if (rst)
> mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
>
> } else if (mcs->new_speed <= 1152000) {
> rval &= ~MCS_FIR;
>
> - if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
> + rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
> + if (rst)
> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>
> } else {
> rval |= MCS_FIR;
>
> - if ((rst = (mcs->speed != 4000000)))
> + rst = (mcs->speed != 4000000);
> + if (rst)
> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>
> }
> diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
> index 160dc89..5aab072 100644
> --- a/drivers/staging/irda/net/irqueue.c
> +++ b/drivers/staging/irda/net/irqueue.c
> @@ -217,7 +217,8 @@ static __u32 hash( const char* name)
>
> while(*name) {
> h = (h<<4) + *name++;
> - if ((g = (h & 0xf0000000)))
> + g = (h & 0xf0000000);
> + if (g)
> h ^=g>>24;
> h &=~g;
> }
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1505504036-21807-1-git-send-email-srishtishar%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH] Staging: irda: Don't use assignment inside if statement
From: Srishti Sharma @ 2017-09-15 19:42 UTC (permalink / raw)
To: Julia Lawall
Cc: devel, samuel, Greg KH, Linux kernel mailing list,
outreachy-kernel, netdev
In-Reply-To: <alpine.DEB.2.20.1709152136200.2533@hadrien>
On Sat, Sep 16, 2017 at 1:08 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
>
> On Sat, 16 Sep 2017, Srishti Sharma wrote:
>
>> Write assignment statement outside the if statement. Done using
>> the following semantic patch by coccinelle.
>>
>> @@
>> identifier E;
>> expression F;
>> statement S;
>> @@
>>
>> -if((E = F))
>> +E = F
>
> The line above would need to end in a ;
Yes, I'll send a v2 after correcting it .
>
> This ends up with a lot of assignments with () around the right hand side.
> Maybe you could make a series removing them afterwards.
Yes, I'll do that . Thanks .
Regards,
Srishti
>
> julia
>
>> +if(E)
>> S
>>
>> Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
>> ---
>> drivers/staging/irda/drivers/irda-usb.c | 4 ++--
>> drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
>> drivers/staging/irda/net/irqueue.c | 3 ++-
>> 3 files changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
>> index 723e49b..82bfc05 100644
>> --- a/drivers/staging/irda/drivers/irda-usb.c
>> +++ b/drivers/staging/irda/drivers/irda-usb.c
>> @@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
>> urb->transfer_flags = 0;
>>
>> /* Irq disabled -> GFP_ATOMIC */
>> - if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
>> + ret = usb_submit_urb(urb, GFP_ATOMIC);
>> + if (ret)
>> net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
>> - }
>> }
>>
>> /*------------------------------------------------------------------*/
>> diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
>> index c3f0b25..2b674d5 100644
>> --- a/drivers/staging/irda/drivers/mcs7780.c
>> +++ b/drivers/staging/irda/drivers/mcs7780.c
>> @@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
>> if (mcs->new_speed <= 115200) {
>> rval &= ~MCS_FIR;
>>
>> - if ((rst = (mcs->speed > 115200)))
>> + rst = (mcs->speed > 115200);
>> + if (rst)
>> mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
>>
>> } else if (mcs->new_speed <= 1152000) {
>> rval &= ~MCS_FIR;
>>
>> - if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
>> + rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
>> + if (rst)
>> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>>
>> } else {
>> rval |= MCS_FIR;
>>
>> - if ((rst = (mcs->speed != 4000000)))
>> + rst = (mcs->speed != 4000000);
>> + if (rst)
>> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>>
>> }
>> diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
>> index 160dc89..5aab072 100644
>> --- a/drivers/staging/irda/net/irqueue.c
>> +++ b/drivers/staging/irda/net/irqueue.c
>> @@ -217,7 +217,8 @@ static __u32 hash( const char* name)
>>
>> while(*name) {
>> h = (h<<4) + *name++;
>> - if ((g = (h & 0xf0000000)))
>> + g = (h & 0xf0000000);
>> + if (g)
>> h ^=g>>24;
>> h &=~g;
>> }
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
>> To post to this group, send email to outreachy-kernel@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1505504036-21807-1-git-send-email-srishtishar%40gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
^ permalink raw reply
* [PATCH v2] Staging: irda: Don't use assignment inside if statement
From: Srishti Sharma @ 2017-09-15 19:44 UTC (permalink / raw)
To: samuel
Cc: gregkh, netdev, devel, linux-kernel, outreachy-kernel,
Srishti Sharma
Write assignment statement outside the if statement. Done using
the following semantic patch by coccinelle.
@@
identifier E;
expression F;
statement S;
@@
-if((E = F))
+E = F;
+if(E)
S
Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
---
Changes in v2:
-Semicolon was missing in one of the statements of the
semantic patch
drivers/staging/irda/drivers/irda-usb.c | 4 ++--
drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
drivers/staging/irda/net/irqueue.c | 3 ++-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
index 723e49b..82bfc05 100644
--- a/drivers/staging/irda/drivers/irda-usb.c
+++ b/drivers/staging/irda/drivers/irda-usb.c
@@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
urb->transfer_flags = 0;
/* Irq disabled -> GFP_ATOMIC */
- if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret)
net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
- }
}
/*------------------------------------------------------------------*/
diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
index c3f0b25..2b674d5 100644
--- a/drivers/staging/irda/drivers/mcs7780.c
+++ b/drivers/staging/irda/drivers/mcs7780.c
@@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
if (mcs->new_speed <= 115200) {
rval &= ~MCS_FIR;
- if ((rst = (mcs->speed > 115200)))
+ rst = (mcs->speed > 115200);
+ if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
} else if (mcs->new_speed <= 1152000) {
rval &= ~MCS_FIR;
- if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
+ rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
+ if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
} else {
rval |= MCS_FIR;
- if ((rst = (mcs->speed != 4000000)))
+ rst = (mcs->speed != 4000000);
+ if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
}
diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
index 160dc89..5aab072 100644
--- a/drivers/staging/irda/net/irqueue.c
+++ b/drivers/staging/irda/net/irqueue.c
@@ -217,7 +217,8 @@ static __u32 hash( const char* name)
while(*name) {
h = (h<<4) + *name++;
- if ((g = (h & 0xf0000000)))
+ g = (h & 0xf0000000);
+ if (g)
h ^=g>>24;
h &=~g;
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v1] bridge: also trigger RTM_NEWLINK when interface is released from bridge
From: Vincent Bernat @ 2017-09-15 19:38 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, bridge, netdev; +Cc: Vincent Bernat
Currently, when an interface is released from a bridge, we get a
RTM_DELLINK event through netlink:
Deleted 2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
link/ether 6e:23:c2:54:3a:b3
Userspace has to interpret that as a removal from the bridge, not as a
complete removal of the interface. When an bridged interface is
completely removed, we get two events:
Deleted 2: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
link/ether 6e:23:c2:54:3a:b3
Deleted 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
link/ether 6e:23:c2:54:3a:b3 brd ff:ff:ff:ff:ff:ff
In constrast, when an interface is released from a bond, we get a
RTM_NEWLINK with only the new characteristics (no master):
3: dummy1: <BROADCAST,NOARP,SLAVE,UP,LOWER_UP> mtu 1500 qdisc noqueue master bond0 state UNKNOWN group default
link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
3: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
3: dummy1: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN group default
link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
3: dummy1: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN group default
link/ether ca:c8:7b:66:f8:25 brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
Userland may be confused by the fact we say a link is deleted while
its characteristics are only modified. A first solution would have
been to turn the RTM_DELLINK event in del_nbp() into a RTM_NEWLINK
event. However, maybe some piece of userland is relying on this
RTM_DELLINK to detect when a bridged interface is released. Instead,
we also emit a RTM_NEWLINK event once the interface is
released (without master info).
Deleted 2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
link/ether 8a:bb:e7:94:b1:f8
2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 8a:bb:e7:94:b1:f8 brd ff:ff:ff:ff:ff:ff
Signed-off-by: Vincent Bernat <vincent@bernat.im>
---
net/bridge/br_if.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index f3aef22931ab..636e0a842f8a 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -288,6 +288,8 @@ static void del_nbp(struct net_bridge_port *p)
dev->priv_flags &= ~IFF_BRIDGE_PORT;
+ rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_MASTER, GFP_KERNEL);
+
netdev_rx_handler_unregister(dev);
br_multicast_del_port(p);
--
2.14.1
^ permalink raw reply related
* Re: [Outreachy kernel] [PATCH v2] Staging: irda: Don't use assignment inside if statement
From: Julia Lawall @ 2017-09-15 20:00 UTC (permalink / raw)
To: Srishti Sharma
Cc: samuel, gregkh, netdev, devel, linux-kernel, outreachy-kernel
In-Reply-To: <1505504680-22167-1-git-send-email-srishtishar@gmail.com>
On Sat, 16 Sep 2017, Srishti Sharma wrote:
> Write assignment statement outside the if statement. Done using
> the following semantic patch by coccinelle.
>
> @@
> identifier E;
> expression F;
> statement S;
> @@
>
> -if((E = F))
> +E = F;
> +if(E)
> S
>
> Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
> Changes in v2:
> -Semicolon was missing in one of the statements of the
> semantic patch
>
> drivers/staging/irda/drivers/irda-usb.c | 4 ++--
> drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
> drivers/staging/irda/net/irqueue.c | 3 ++-
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
> index 723e49b..82bfc05 100644
> --- a/drivers/staging/irda/drivers/irda-usb.c
> +++ b/drivers/staging/irda/drivers/irda-usb.c
> @@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
> urb->transfer_flags = 0;
>
> /* Irq disabled -> GFP_ATOMIC */
> - if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
> + ret = usb_submit_urb(urb, GFP_ATOMIC);
> + if (ret)
> net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
> - }
> }
>
> /*------------------------------------------------------------------*/
> diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
> index c3f0b25..2b674d5 100644
> --- a/drivers/staging/irda/drivers/mcs7780.c
> +++ b/drivers/staging/irda/drivers/mcs7780.c
> @@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
> if (mcs->new_speed <= 115200) {
> rval &= ~MCS_FIR;
>
> - if ((rst = (mcs->speed > 115200)))
> + rst = (mcs->speed > 115200);
> + if (rst)
> mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
>
> } else if (mcs->new_speed <= 1152000) {
> rval &= ~MCS_FIR;
>
> - if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
> + rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
> + if (rst)
> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>
> } else {
> rval |= MCS_FIR;
>
> - if ((rst = (mcs->speed != 4000000)))
> + rst = (mcs->speed != 4000000);
> + if (rst)
> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>
> }
> diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
> index 160dc89..5aab072 100644
> --- a/drivers/staging/irda/net/irqueue.c
> +++ b/drivers/staging/irda/net/irqueue.c
> @@ -217,7 +217,8 @@ static __u32 hash( const char* name)
>
> while(*name) {
> h = (h<<4) + *name++;
> - if ((g = (h & 0xf0000000)))
> + g = (h & 0xf0000000);
> + if (g)
> h ^=g>>24;
> h &=~g;
> }
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1505504680-22167-1-git-send-email-srishtishar%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply
* Re: [PATCH net] packet: hold bind lock when rebinding to fanout hook
From: Willem de Bruijn @ 2017-09-15 20:01 UTC (permalink / raw)
To: Cong Wang
Cc: Willem de Bruijn, Linux Kernel Network Developers, David Miller,
nixiaoming
In-Reply-To: <CAM_iQpXOS3cB8GtuVZaQq7AnFkHQXxcBqkg0azMU-JpMtv4NRw@mail.gmail.com>
>> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>> index c26172995511..d288f52c53f7 100644
>> --- a/net/packet/af_packet.c
>> +++ b/net/packet/af_packet.c
>> @@ -1684,10 +1684,6 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
>>
>> mutex_lock(&fanout_mutex);
>>
>> - err = -EINVAL;
>> - if (!po->running)
>> - goto out;
>> -
>> err = -EALREADY;
>> if (po->fanout)
>> goto out;
>> @@ -1749,7 +1745,10 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
>> list_add(&match->list, &fanout_list);
>> }
>> err = -EINVAL;
>> - if (match->type == type &&
>> +
>> + spin_lock(&po->bind_lock);
>> + if (po->running &&
>
>
> As you move the po->running check later after setting po->rollover, I wonder
> if po->rollover possibly depends on po>running on other path?
The rollover code does not explicitly check po->running, if that is
what you are concerned about.
A newly allocated po->rollover structure will also only be accessed
from the datapath once the socket is added to a fanout group. Both
before and after this patch, that happens well after the po->running
check.
If the socket already had a po->rollover, then it must already have
had a po->fanout, too, so fanout_add does not reach this code.
>> + match->type == type &&
>> match->prot_hook.type == po->prot_hook.type &&
>> match->prot_hook.dev == po->prot_hook.dev) {
>> err = -ENOSPC;
>> @@ -1761,6 +1760,13 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
>> err = 0;
>> }
>> }
>> + spin_unlock(&po->bind_lock);
>> +
>> + if (err && !refcount_read(&match->sk_ref)) {
>> + list_del(&match->list);
>> + kfree(match);
>> + }
>
> This looks correct but still seems odd, it smells you don't use refcnt in an
> expected way.
It tests whether the object has no references, in which case it must have
been newly allocated and the fanout join operation must have failed.
I don't see an obviously simpler patch.
The entire code could perhaps be restructured eventually. There is,
for instance, no reason to test match->{type, prot_hook.type, prot_hook.dev}
when having just allocated the structure. Nor to test whether sk_ref exceeds
PACKET_FANOUT_MAX. Conversely, this sk_ref == 0 test only makes sense
when having taken the (!match) branch earlier.
But a refactor is out of scope for a bug fix.
^ permalink raw reply
* [PATCH iproute2] Add information about COLORFGBG to ip.8 man page
From: Roland Hopferwieser @ 2017-09-15 20:04 UTC (permalink / raw)
To: netdev
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index ae018fdf..2a27a56e 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -187,7 +187,8 @@ executes specified command over all objects, it
depends if command supports this
.TP
.BR "\-c" , " -color"
-Use color output.
+Use color output. The color palette is affected by the COLORFGBG
environment variable, which typically has the form "fg;bg".
+If "bg" is set to 0-6 or 8, the dark color palette is used.
.TP
.BR "\-t" , " \-timestamp"
^ permalink raw reply related
* Re: [PATCH net] l2tp: fix race condition in l2tp_tunnel_delete
From: Guillaume Nault @ 2017-09-15 20:38 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: Tom Parkin, netdev, Xin Long
In-Reply-To: <20170915145502.GA18157@bistromath.localdomain>
On Fri, Sep 15, 2017 at 04:55:02PM +0200, Sabrina Dubroca wrote:
> 2017-09-15, 10:42:59 +0100, Tom Parkin wrote:
> > On Fri, Sep 15, 2017 at 11:08:07AM +0200, Sabrina Dubroca wrote:
> > > The tunnel is currently removed from the list during destruction. This
> > > can lead to a double-free of the struct sock if we try to delete the tunnel
> > > twice fast enough.
> > >
> > > The first delete operation does a lookup (l2tp_tunnel_get), finds the
> > > tunnel, calls l2tp_tunnel_delete, which queues it for deletion by
> > > l2tp_tunnel_del_work.
> > >
> > > The second delete operation also finds the tunnel and calls
> > > l2tp_tunnel_delete. If the workqueue has already fired and started
> > > running l2tp_tunnel_del_work, then l2tp_tunnel_delete will queue the
> > > same tunnel a second time, and try to free the socket again.
> > >
> > > Add a dead flag and remove tunnel from its list earlier. Then we can
> > > remove the check of queue_work's result that was meant to prevent that
> > > race but doesn't.
> >
> > How do we avoid leaving stale information on the tunnel list for
> > use-cases which don't delete tunnels using netlink? For example the
> > L2TPv2 ppp/socket API depends on sk_destruct to clean up the kernel
> > context on socket destruction. Similarly, userspace may just close
> > the tunnel socket without first making netlink calls to delete the
> > tunnel.
> >
> > By moving the tunnel list removal from l2tp_tunnel_destruct to
> > l2tp_tunnel_delete I can't see how codepaths which don't involve
> > l2tp_tunnel_delete don't end up with a corrupted tunnel list.
>
> Ok, thanks for pointing that out. We could go with just the ->dead
> flag then.
>
Yes, I guess that's the least instrusive way to fix this issue.
> I'm not sure whether we need to set it in l2tp_tunnel_destruct as
> well.
>
It shouldn't be necessary. If the socket is managed by userspace, then
l2tp_tunnel_del_work() gets it using sockfd_lookup(). Therefore it
shouldn't find it if userspace is in the process of releasing it.
Also l2tp_tunnel_del_work() doesn't try to release sockets handled by
userspace, so not checking ->dead in l2tp_tunnel_destruct() should be
safe.
^ permalink raw reply
* Re: Use after free in __dst_destroy_metrics_generic
From: Eric Dumazet @ 2017-09-15 21:00 UTC (permalink / raw)
To: Cong Wang
Cc: Subash Abhinov Kasiviswanathan, Linux Kernel Network Developers,
Lorenzo Colitti
In-Reply-To: <CAM_iQpXKfUkbyuuZEZXyPrVVCoPaxnCmCARz=Jf0VtU1m9NsZg@mail.gmail.com>
On Fri, 2017-09-08 at 09:10 -0700, Cong Wang wrote:
> On Thu, Sep 7, 2017 at 5:52 PM, Subash Abhinov Kasiviswanathan
> <subashab@codeaurora.org> wrote:
> > We are seeing a possible use after free in ip6_dst_destroy.
> >
> > It appears as if memory of the __DST_METRICS_PTR(old) was freed in some path
> > and allocated
> > to ion driver. ion driver has also freed it. Finally the memory is freed by
> > the
> > fib gc and crashes since it is already deallocated.
>
> Does the attach (compile-only) patch help anything?
>
> From my _quick_ glance, it seems we miss the refcnt'ing
> right in __dst_destroy_metrics_generic().
>
> Thanks!
Hi Cong
I believe your patch makes a lot of sense, please submit it formally ?
Thanks !
^ permalink raw reply
* Re: [PATCH] qed: remove unnecessary call to memset
From: David Miller @ 2017-09-15 21:02 UTC (permalink / raw)
To: himanshujha199640
Cc: Yuval.Mintz, Ariel.Elior, everest-linux-l2, netdev, linux-kernel
In-Reply-To: <1505215162-3917-1-git-send-email-himanshujha199640@gmail.com>
From: Himanshu Jha <himanshujha199640@gmail.com>
Date: Tue, 12 Sep 2017 16:49:22 +0530
> call to memset to assign 0 value immediately after allocating
> memory with kzalloc is unnecesaary as kzalloc allocates the memory
> filled with 0 value.
>
> Semantic patch used to resolve this issue:
>
> @@
> expression e,e2; constant c;
> statement S;
> @@
>
> e = kzalloc(e2, c);
> if(e == NULL) S
> - memset(e, 0, e2);
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Applied.
^ permalink raw reply
* [PATCH 0/2] Assign outside if
From: Srishti Sharma @ 2017-09-15 21:05 UTC (permalink / raw)
To: samuel
Cc: gregkh, netdev, devel, linux-kernel, outreachy-kernel,
Srishti Sharma
This patch series intends to remove the assignment statements
inside the if statement, and eliminates the cases of parentheses
around the right hand side of assignment generated as a result of
the same.
Srishti Sharma (2):
Staging: irda: Don't use assignment inside if statement
Staging: irda: Remove parentheses on the right of assignment
drivers/staging/irda/drivers/irda-usb.c | 4 ++--
drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
drivers/staging/irda/net/irqueue.c | 3 ++-
3 files changed, 10 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] Staging: irda: Don't use assignment inside if statement
From: Srishti Sharma @ 2017-09-15 21:05 UTC (permalink / raw)
To: samuel
Cc: gregkh, netdev, devel, linux-kernel, outreachy-kernel,
Srishti Sharma
In-Reply-To: <cover.1505508423.git.srishtishar@gmail.com>
Write assignment statement outside of the if statement. Done
using the following semantic patch by coccinelle.
@@
identifier E;
expression F;
statement S;
@@
-if((E = F))
+E = F;
+if(E)
S
Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
---
drivers/staging/irda/drivers/irda-usb.c | 4 ++--
drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
drivers/staging/irda/net/irqueue.c | 3 ++-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
index 723e49b..82bfc05 100644
--- a/drivers/staging/irda/drivers/irda-usb.c
+++ b/drivers/staging/irda/drivers/irda-usb.c
@@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
urb->transfer_flags = 0;
/* Irq disabled -> GFP_ATOMIC */
- if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret)
net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
- }
}
/*------------------------------------------------------------------*/
diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
index c3f0b25..2b674d5 100644
--- a/drivers/staging/irda/drivers/mcs7780.c
+++ b/drivers/staging/irda/drivers/mcs7780.c
@@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
if (mcs->new_speed <= 115200) {
rval &= ~MCS_FIR;
- if ((rst = (mcs->speed > 115200)))
+ rst = (mcs->speed > 115200);
+ if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
} else if (mcs->new_speed <= 1152000) {
rval &= ~MCS_FIR;
- if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
+ rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
+ if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
} else {
rval |= MCS_FIR;
- if ((rst = (mcs->speed != 4000000)))
+ rst = (mcs->speed != 4000000);
+ if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
}
diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
index 160dc89..5aab072 100644
--- a/drivers/staging/irda/net/irqueue.c
+++ b/drivers/staging/irda/net/irqueue.c
@@ -217,7 +217,8 @@ static __u32 hash( const char* name)
while(*name) {
h = (h<<4) + *name++;
- if ((g = (h & 0xf0000000)))
+ g = (h & 0xf0000000);
+ if (g)
h ^=g>>24;
h &=~g;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] Staging: irda: Remove parentheses on the right of assignment
From: Srishti Sharma @ 2017-09-15 21:06 UTC (permalink / raw)
To: samuel
Cc: devel, gregkh, linux-kernel, outreachy-kernel, Srishti Sharma,
netdev
In-Reply-To: <cover.1505508423.git.srishtishar@gmail.com>
Parentheses are not needed on the right hand side of assignment
statement in most cases. Done using the following semantic
patch by coccinelle.
@@
identifier E,F,G,f;
expression e,r;
@@
(
E = (G == F);
|
E = (e == r);
|
E =
-(
...
-)
;
)
Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
---
drivers/staging/irda/drivers/mcs7780.c | 4 ++--
drivers/staging/irda/net/irqueue.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
index 2b674d5..d52e9f4 100644
--- a/drivers/staging/irda/drivers/mcs7780.c
+++ b/drivers/staging/irda/drivers/mcs7780.c
@@ -605,7 +605,7 @@ static int mcs_speed_change(struct mcs_cb *mcs)
if (mcs->new_speed <= 115200) {
rval &= ~MCS_FIR;
- rst = (mcs->speed > 115200);
+ rst = mcs->speed > 115200;
if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
@@ -619,7 +619,7 @@ static int mcs_speed_change(struct mcs_cb *mcs)
} else {
rval |= MCS_FIR;
- rst = (mcs->speed != 4000000);
+ rst = mcs->speed != 4000000;
if (rst)
mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
index 5aab072..14291cb 100644
--- a/drivers/staging/irda/net/irqueue.c
+++ b/drivers/staging/irda/net/irqueue.c
@@ -217,7 +217,7 @@ static __u32 hash( const char* name)
while(*name) {
h = (h<<4) + *name++;
- g = (h & 0xf0000000);
+ g = h & 0xf0000000;
if (g)
h ^=g>>24;
h &=~g;
--
2.7.4
^ permalink raw reply related
* Re: [Outreachy kernel] [PATCH v2] Staging: irda: Don't use assignment inside if statement
From: Srishti Sharma @ 2017-09-15 21:07 UTC (permalink / raw)
To: Julia Lawall
Cc: samuel, Greg KH, netdev, devel, Linux kernel mailing list,
outreachy-kernel
In-Reply-To: <alpine.DEB.2.20.1709152200030.2533@hadrien>
On Sat, Sep 16, 2017 at 1:30 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
>
> On Sat, 16 Sep 2017, Srishti Sharma wrote:
>
>> Write assignment statement outside the if statement. Done using
>> the following semantic patch by coccinelle.
>>
>> @@
>> identifier E;
>> expression F;
>> statement S;
>> @@
>>
>> -if((E = F))
>> +E = F;
>> +if(E)
>> S
>>
>> Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
>
> Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Have sent a patchset for this instead .
Regards,
Srishti
>
>> ---
>> Changes in v2:
>> -Semicolon was missing in one of the statements of the
>> semantic patch
>>
>> drivers/staging/irda/drivers/irda-usb.c | 4 ++--
>> drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
>> drivers/staging/irda/net/irqueue.c | 3 ++-
>> 3 files changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
>> index 723e49b..82bfc05 100644
>> --- a/drivers/staging/irda/drivers/irda-usb.c
>> +++ b/drivers/staging/irda/drivers/irda-usb.c
>> @@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
>> urb->transfer_flags = 0;
>>
>> /* Irq disabled -> GFP_ATOMIC */
>> - if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
>> + ret = usb_submit_urb(urb, GFP_ATOMIC);
>> + if (ret)
>> net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
>> - }
>> }
>>
>> /*------------------------------------------------------------------*/
>> diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
>> index c3f0b25..2b674d5 100644
>> --- a/drivers/staging/irda/drivers/mcs7780.c
>> +++ b/drivers/staging/irda/drivers/mcs7780.c
>> @@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
>> if (mcs->new_speed <= 115200) {
>> rval &= ~MCS_FIR;
>>
>> - if ((rst = (mcs->speed > 115200)))
>> + rst = (mcs->speed > 115200);
>> + if (rst)
>> mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
>>
>> } else if (mcs->new_speed <= 1152000) {
>> rval &= ~MCS_FIR;
>>
>> - if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
>> + rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
>> + if (rst)
>> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>>
>> } else {
>> rval |= MCS_FIR;
>>
>> - if ((rst = (mcs->speed != 4000000)))
>> + rst = (mcs->speed != 4000000);
>> + if (rst)
>> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>>
>> }
>> diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
>> index 160dc89..5aab072 100644
>> --- a/drivers/staging/irda/net/irqueue.c
>> +++ b/drivers/staging/irda/net/irqueue.c
>> @@ -217,7 +217,8 @@ static __u32 hash( const char* name)
>>
>> while(*name) {
>> h = (h<<4) + *name++;
>> - if ((g = (h & 0xf0000000)))
>> + g = (h & 0xf0000000);
>> + if (g)
>> h ^=g>>24;
>> h &=~g;
>> }
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
>> To post to this group, send email to outreachy-kernel@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1505504680-22167-1-git-send-email-srishtishar%40gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH v2] Staging: irda: Don't use assignment inside if statement
From: Julia Lawall @ 2017-09-15 21:09 UTC (permalink / raw)
To: Srishti Sharma
Cc: samuel, Greg KH, netdev, devel, Linux kernel mailing list,
outreachy-kernel
In-Reply-To: <CAB3L5oxr5K5aMo06ROCVV9ejY6a_g1+uUkjU=Z5bKTJtzUs7sA@mail.gmail.com>
On Sat, 16 Sep 2017, Srishti Sharma wrote:
> On Sat, Sep 16, 2017 at 1:30 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> >
> >
> > On Sat, 16 Sep 2017, Srishti Sharma wrote:
> >
> >> Write assignment statement outside the if statement. Done using
> >> the following semantic patch by coccinelle.
> >>
> >> @@
> >> identifier E;
> >> expression F;
> >> statement S;
> >> @@
> >>
> >> -if((E = F))
> >> +E = F;
> >> +if(E)
> >> S
> >>
> >> Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
> >
> > Acked-by: Julia Lawall <julia.lawall@lip6.fr>
>
> Have sent a patchset for this instead .
Thanks. Actually, you should have copied the ack.
julia
>
> Regards,
> Srishti
> >
> >> ---
> >> Changes in v2:
> >> -Semicolon was missing in one of the statements of the
> >> semantic patch
> >>
> >> drivers/staging/irda/drivers/irda-usb.c | 4 ++--
> >> drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
> >> drivers/staging/irda/net/irqueue.c | 3 ++-
> >> 3 files changed, 10 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
> >> index 723e49b..82bfc05 100644
> >> --- a/drivers/staging/irda/drivers/irda-usb.c
> >> +++ b/drivers/staging/irda/drivers/irda-usb.c
> >> @@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
> >> urb->transfer_flags = 0;
> >>
> >> /* Irq disabled -> GFP_ATOMIC */
> >> - if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
> >> + ret = usb_submit_urb(urb, GFP_ATOMIC);
> >> + if (ret)
> >> net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
> >> - }
> >> }
> >>
> >> /*------------------------------------------------------------------*/
> >> diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
> >> index c3f0b25..2b674d5 100644
> >> --- a/drivers/staging/irda/drivers/mcs7780.c
> >> +++ b/drivers/staging/irda/drivers/mcs7780.c
> >> @@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
> >> if (mcs->new_speed <= 115200) {
> >> rval &= ~MCS_FIR;
> >>
> >> - if ((rst = (mcs->speed > 115200)))
> >> + rst = (mcs->speed > 115200);
> >> + if (rst)
> >> mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
> >>
> >> } else if (mcs->new_speed <= 1152000) {
> >> rval &= ~MCS_FIR;
> >>
> >> - if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
> >> + rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
> >> + if (rst)
> >> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
> >>
> >> } else {
> >> rval |= MCS_FIR;
> >>
> >> - if ((rst = (mcs->speed != 4000000)))
> >> + rst = (mcs->speed != 4000000);
> >> + if (rst)
> >> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
> >>
> >> }
> >> diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
> >> index 160dc89..5aab072 100644
> >> --- a/drivers/staging/irda/net/irqueue.c
> >> +++ b/drivers/staging/irda/net/irqueue.c
> >> @@ -217,7 +217,8 @@ static __u32 hash( const char* name)
> >>
> >> while(*name) {
> >> h = (h<<4) + *name++;
> >> - if ((g = (h & 0xf0000000)))
> >> + g = (h & 0xf0000000);
> >> + if (g)
> >> h ^=g>>24;
> >> h &=~g;
> >> }
> >> --
> >> 2.7.4
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> >> To post to this group, send email to outreachy-kernel@googlegroups.com.
> >> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1505504680-22167-1-git-send-email-srishtishar%40gmail.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >>
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/CAB3L5oxr5K5aMo06ROCVV9ejY6a_g1%2BuUkjU%3DZ5bKTJtzUs7sA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply
* Re: [PATCH net] ipv6: fix net.ipv6.conf.all interface DAD handlers
From: David Miller @ 2017-09-15 21:12 UTC (permalink / raw)
To: mcroce; +Cc: netdev, linux-doc, ek
In-Reply-To: <20170912154637.12996-1-mcroce@redhat.com>
From: Matteo Croce <mcroce@redhat.com>
Date: Tue, 12 Sep 2017 17:46:37 +0200
> Currently, writing into
> net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect.
> Fix handling of these flags by:
>
> - using the maximum of global and per-interface values for the
> accept_dad flag. That is, if at least one of the two values is
> non-zero, enable DAD on the interface. If at least one value is
> set to 2, enable DAD and disable IPv6 operation on the interface if
> MAC-based link-local address was found
>
> - using the logical OR of global and per-interface values for the
> optimistic_dad flag. If at least one of them is set to one, optimistic
> duplicate address detection (RFC 4429) is enabled on the interface
>
> - using the logical OR of global and per-interface values for the
> use_optimistic flag. If at least one of them is set to one,
> optimistic addresses won't be marked as deprecated during source address
> selection on the interface.
>
> While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(),
> drop inline, and let the compiler decide.
>
> Fixes: 7fd2561e4ebd ("net: ipv6: Add a sysctl to make optimistic addresses useful candidates")
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
Erik, please review.
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH v2] Staging: irda: Don't use assignment inside if statement
From: Srishti Sharma @ 2017-09-15 21:14 UTC (permalink / raw)
To: Julia Lawall
Cc: devel, samuel, Greg KH, Linux kernel mailing list,
outreachy-kernel, netdev
In-Reply-To: <alpine.DEB.2.20.1709152308300.2533@hadrien>
On Sat, Sep 16, 2017 at 2:39 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
>
> On Sat, 16 Sep 2017, Srishti Sharma wrote:
>
>> On Sat, Sep 16, 2017 at 1:30 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>> >
>> >
>> > On Sat, 16 Sep 2017, Srishti Sharma wrote:
>> >
>> >> Write assignment statement outside the if statement. Done using
>> >> the following semantic patch by coccinelle.
>> >>
>> >> @@
>> >> identifier E;
>> >> expression F;
>> >> statement S;
>> >> @@
>> >>
>> >> -if((E = F))
>> >> +E = F;
>> >> +if(E)
>> >> S
>> >>
>> >> Signed-off-by: Srishti Sharma <srishtishar@gmail.com>
>> >
>> > Acked-by: Julia Lawall <julia.lawall@lip6.fr>
>>
>> Have sent a patchset for this instead .
>
> Thanks. Actually, you should have copied the ack.
Oh.. Sorry didn't realise I could do that :)
Regards,
Srishti
>
> julia
>
>>
>> Regards,
>> Srishti
>> >
>> >> ---
>> >> Changes in v2:
>> >> -Semicolon was missing in one of the statements of the
>> >> semantic patch
>> >>
>> >> drivers/staging/irda/drivers/irda-usb.c | 4 ++--
>> >> drivers/staging/irda/drivers/mcs7780.c | 9 ++++++---
>> >> drivers/staging/irda/net/irqueue.c | 3 ++-
>> >> 3 files changed, 10 insertions(+), 6 deletions(-)
>> >>
>> >> diff --git a/drivers/staging/irda/drivers/irda-usb.c b/drivers/staging/irda/drivers/irda-usb.c
>> >> index 723e49b..82bfc05 100644
>> >> --- a/drivers/staging/irda/drivers/irda-usb.c
>> >> +++ b/drivers/staging/irda/drivers/irda-usb.c
>> >> @@ -334,9 +334,9 @@ static void irda_usb_change_speed_xbofs(struct irda_usb_cb *self)
>> >> urb->transfer_flags = 0;
>> >>
>> >> /* Irq disabled -> GFP_ATOMIC */
>> >> - if ((ret = usb_submit_urb(urb, GFP_ATOMIC))) {
>> >> + ret = usb_submit_urb(urb, GFP_ATOMIC);
>> >> + if (ret)
>> >> net_warn_ratelimited("%s(), failed Speed URB\n", __func__);
>> >> - }
>> >> }
>> >>
>> >> /*------------------------------------------------------------------*/
>> >> diff --git a/drivers/staging/irda/drivers/mcs7780.c b/drivers/staging/irda/drivers/mcs7780.c
>> >> index c3f0b25..2b674d5 100644
>> >> --- a/drivers/staging/irda/drivers/mcs7780.c
>> >> +++ b/drivers/staging/irda/drivers/mcs7780.c
>> >> @@ -605,19 +605,22 @@ static int mcs_speed_change(struct mcs_cb *mcs)
>> >> if (mcs->new_speed <= 115200) {
>> >> rval &= ~MCS_FIR;
>> >>
>> >> - if ((rst = (mcs->speed > 115200)))
>> >> + rst = (mcs->speed > 115200);
>> >> + if (rst)
>> >> mcs_set_reg(mcs, MCS_MINRXPW_REG, 0);
>> >>
>> >> } else if (mcs->new_speed <= 1152000) {
>> >> rval &= ~MCS_FIR;
>> >>
>> >> - if ((rst = !(mcs->speed == 576000 || mcs->speed == 1152000)))
>> >> + rst = !(mcs->speed == 576000 || mcs->speed == 1152000);
>> >> + if (rst)
>> >> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>> >>
>> >> } else {
>> >> rval |= MCS_FIR;
>> >>
>> >> - if ((rst = (mcs->speed != 4000000)))
>> >> + rst = (mcs->speed != 4000000);
>> >> + if (rst)
>> >> mcs_set_reg(mcs, MCS_MINRXPW_REG, 5);
>> >>
>> >> }
>> >> diff --git a/drivers/staging/irda/net/irqueue.c b/drivers/staging/irda/net/irqueue.c
>> >> index 160dc89..5aab072 100644
>> >> --- a/drivers/staging/irda/net/irqueue.c
>> >> +++ b/drivers/staging/irda/net/irqueue.c
>> >> @@ -217,7 +217,8 @@ static __u32 hash( const char* name)
>> >>
>> >> while(*name) {
>> >> h = (h<<4) + *name++;
>> >> - if ((g = (h & 0xf0000000)))
>> >> + g = (h & 0xf0000000);
>> >> + if (g)
>> >> h ^=g>>24;
>> >> h &=~g;
>> >> }
>> >> --
>> >> 2.7.4
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
>> >> To post to this group, send email to outreachy-kernel@googlegroups.com.
>> >> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1505504680-22167-1-git-send-email-srishtishar%40gmail.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
>> To post to this group, send email to outreachy-kernel@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/CAB3L5oxr5K5aMo06ROCVV9ejY6a_g1%2BuUkjU%3DZ5bKTJtzUs7sA%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
^ permalink raw reply
* Re: [PATCH] VSOCK: fix uapi/linux/vm_sockets.h incomplete types
From: David Miller @ 2017-09-15 21:14 UTC (permalink / raw)
To: stefanha; +Cc: netdev, jhansen
In-Reply-To: <20170912163435.4049-1-stefanha@redhat.com>
From: Stefan Hajnoczi <stefanha@redhat.com>
Date: Tue, 12 Sep 2017 17:34:35 +0100
> This patch fixes the following compiler errors when userspace
> applications use the vm_sockets.h header:
>
> include/uapi/linux/vm_sockets.h:148:32: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr’
> unsigned char svm_zero[sizeof(struct sockaddr) -
> ^~~~~~
> include/uapi/linux/vm_sockets.h:149:18: error: ‘sa_family_t’ undeclared here (not in a function)
> sizeof(sa_family_t) -
> ^~~~~~~~~~~
>
> Two issues:
> 1. In the kernel struct sockaddr comes in via <linux/socket.h> but in
> userspace <sys/socket.h> is required.
> 2. struct sockaddr_vm has a __kernel_sa_family_t field so let's be
> consistent and use the same type for the sizeof(sa_family_t)
> calculation.
>
> Currently userspace applications work around this broken header by first
> including <sys/socket.h>. In the kernel there is no compiler error
> because <linux/socket.h> provides everything. It's worth fixing the
> header file though.
>
> Cc: Jorgen Hansen <jhansen@vmware.com>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> include/uapi/linux/vm_sockets.h | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
> index b4ed5d895699..4ae5c625ac56 100644
> --- a/include/uapi/linux/vm_sockets.h
> +++ b/include/uapi/linux/vm_sockets.h
> @@ -18,6 +18,10 @@
>
> #include <linux/socket.h>
>
> +#ifndef __KERNEL__
> +#include <sys/socket.h> /* struct sockaddr */
> +#endif
> +
There is no precedence whatsoever to include sys/socket.h in _any_ UAPI
header file provided by the kernel.
__kernel_sa_family_t is what should be used in UAPI headers, only
non-UAPI headers can use plain sa_family_t.
So that is the correct fix for this problem.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v1] bridge: also trigger RTM_NEWLINK when interface is released from bridge
From: Vincent Bernat @ 2017-09-15 21:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, bridge, netdev
In-Reply-To: <20170915193808.22338-1-vincent@bernat.im>
❦ 15 septembre 2017 21:38 +0200, Vincent Bernat <vincent@bernat.im> :
> Currently, when an interface is released from a bridge, we get a
> RTM_DELLINK event through netlink:
>
> Deleted 2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 6e:23:c2:54:3a:b3
It should be noted this only happens when using the ioctl API. When
using the netlink API, rtnetlink.c will send a RTM_NEWLINK because of
the modification.
--
When in doubt, tell the truth.
-- Mark Twain
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox