Re: [PATCH 2/5] cifsd: add server-side procedures for SMB3

[Sebastian Gottschall]

Am 23.03.2021 um 08:19 schrieb Dan Carpenter:

On Tue, Mar 23, 2021 at 08:17:47AM +0900, Namjae Jeon wrote:

+
+static int
+compare_oid(unsigned long *oid1, unsigned int oid1len,
+   unsigned long *oid2, unsigned int oid2len) {
+   unsigned int i;
+
+   if (oid1len != oid2len)
+   return 0;
+
+   for (i = 0; i < oid1len; i++) {
+   if (oid1[i] != oid2[i])
+   return 0;
+   }
+   return 1;
+}

Call this oid_eq()?

Why not compare_oid()? This code is come from cifs.
I need clear reason to change both cifs/cifsd...


Boolean functions should tell you what they are testing in the name.
Without any context you can't know what if (compare_oid(one, two)) {
means, but if (oid_equal(one, two)) { is readable.

regards,
dan carpenter

ahm just a pointless comment. but
return !memcmp(oid1,oid2, sizeof(long*)*oid1len);
looks much more efficient than this "for" loop

Re: [PATCH v21 10/10] fs/ntfs3: Add MAINTAINERS

[Sebastian Gottschall]

Am 12.02.2021 um 17:24 schrieb Konstantin Komarov:

This adds MAINTAINERS

Signed-off-by: Konstantin Komarov 


just for your info with latest ntfs3 driver

kern.err kernel: ntfs3: sda1: ntfs_evict_inode r=fe1 failed, -22.

Re: [RFC 0/7] Add support to process rx packets in thread

[Sebastian Gottschall]

i agree. i just can say that i tested this patch recently due this
discussion here. and it can be changed by sysfs. but it doesnt work for
wifi drivers which are mainly using dummy netdev devices. for this i
made a small patch to get them working using napi_set_threaded manually
hardcoded in the drivers. (see patch bellow)

By CONFIG_THREADED_NAPI, there is no need to consider what you did here
in the napi core because device drivers know better and are responsible
for it before calling napi_schedule(n).
yeah. but that approach will not work for some cases. some stupid 
drivers are using locking context in the napi poll function.
in that case the performance will runto shit. i discovered this with the 
mvneta eth driver (marvell) and mt76 tx polling (rx  works)
for mvneta is will cause very high latencies and packet drops. for mt76 
it causes packet stop. doesnt work simply (on all cases no crashes)
so the threading will only work for drivers which are compatible with 
that approach. it cannot be used as drop in replacement from my point of 
view.

its all a question of the driver design

Re: [RFC 0/7] Add support to process rx packets in thread

[Sebastian Gottschall]

Am 25.07.2020 um 14:25 schrieb Hillf Danton:

On Sat, 25 Jul 2020 12:38:00 +0200 Sebastian Gottschall wrote:

you may consider this

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1142611.html 

<https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1142611.html> 


Thanks very much for your link.


years ago someone already wanted to bring this feature upstream, but it
was denied. i already tested this patch the last 2 days and it worked so
far (with some little modifications)
so such a solution existed already and may be considered here

I don't see outstanding difference in principle from Paolo's work in
2016 except for the use of kthread_create() and friends because kworker
made use of them even before 2016. This is a simpler one as shown by
the diff stat in his cover letter.
i agree. i just can say that i tested this patch recently due this 
discussion here. and it can be changed by sysfs. but it doesnt work for
wifi drivers which are mainly using dummy netdev devices. for this i 
made a small patch to get them working using napi_set_threaded manually 
hardcoded in the drivers. (see patch bellow)
i also tested various networking drivers. one thing i notice doesnt 
work. some napi code is used for tx polling. so from my experience this 
concept just works good for rx with the most drivers.
so far i tested mt76, ath10k and some soc ethernet chipsets with good 
success. on ath10k i had about 10 - 20% performance gain on multicore 
systems. using standard iperf3 with 4 parallel streams.


-5439,7 +5441,7 @@ int napi_set_threaded(struct napi_struct *n, bool
    clear_bit(NAPI_STATE_THREADED, >state);

    /* if the device is initializing, nothing todo */
-   if (test_bit(__LINK_STATE_START, >dev->state))
+   if (test_bit(__LINK_STATE_START, >dev->state) && 
n->dev->reg_state != NETREG_DUMMY)

    return 0;

    napi_thread_stop(n)
;




Paolo, feel free to correct me if I misread anything.

Finally I don't see the need to add sysfs attr, given 
CONFIG_THREADED_NAPI

in this work.

BTW let us know if anyone has plans to pick up the 2016 RFC.

Hillf

Paolo Abeni (2):
   net: implement threaded-able napi poll loop support
   net: add sysfs attribute to control napi threaded mode

  include/linux/netdevice.h |   4 ++
  net/core/dev.c    | 113 
++
  net/core/net-sysfs.c  | 102 
+

  3 files changed, 219 insertions(+)

Sebastian


someone

Am 25.07.2020 um 10:16 schrieb Hillf Danton:

On Wed, 22 Jul 2020 09:12:42 + David Laight wrote:

On 21 July 2020 18:25 Andrew Lunn wrote:

On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:

NAPI gets scheduled on the CPU core which got the
interrupt. The linux scheduler cannot move it to a
different core, even if the CPU on which NAPI is running
is heavily loaded. This can lead to degraded wifi
performance when running traffic at peak data rates.

A thread on the other hand can be moved to different
CPU cores, if the one on which its running is heavily
loaded. During high incoming data traffic, this gives
better performance, since the thread can be moved to a
less loaded or sometimes even a more powerful CPU core
to account for the required CPU performance in order
to process the incoming packets.

This patch series adds the support to use a high priority
thread to process the incoming packets, as opposed to
everything being done in NAPI context.
I don't see why this problem is limited to the ath10k driver. I 
expect
it applies to all drivers using NAPI. So shouldn't you be solving 
this

in the NAPI core? Allow a driver to request the NAPI core uses a
thread?

It's not just NAPI the problem is with the softint processing.
I suspect a lot of systems would work better if it ran as
a (highish priority) kernel thread.

Hi folks

Below is a minimunm poc implementation I can imagine on top of 
workqueue

to make napi threaded. Thoughts are appreciated.


I've had to remove the main locks from a multi-threaded application
and replace them with atomic counters.
Consider what happens when the threads remove items from a shared
work list.
The code looks like:
mutex_enter();
remove_item_from_list();
mutex_exit().
The mutex is only held for a few instructions, so while you'd expect
the cache line to be 'hot' you wouldn't get real contention.
However the following scenarios happen:
1) An ethernet interrupt happens while the mutex is held.
 This stops the other threads until all the softint processing
 has finished.
2) An ethernet interrupt (and softint) runs on a thread that is
 waiting for the mutex.
 (Or on the cpu that the thread's processor affinity ties it to.)
 In this case the 'fair' (ticket) mutex code won't let any other
 thread acquire the mutex.
 So again everything stops until the softints all complete.

The second one is al

Re: [RFC 0/7] Add support to process rx packets in thread

[Sebastian Gottschall]

you may consider this

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1142611.html 



years ago someone already wanted to bring this feature upstream, but it 
was denied. i already tested this patch the last 2 days and it worked so 
far (with some little modifications)

so such a solution existed already and may be considered here

Sebastian


someone

Am 25.07.2020 um 10:16 schrieb Hillf Danton:

On Wed, 22 Jul 2020 09:12:42 + David Laight wrote:

On 21 July 2020 18:25 Andrew Lunn wrote:

On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:

NAPI gets scheduled on the CPU core which got the
interrupt. The linux scheduler cannot move it to a
different core, even if the CPU on which NAPI is running
is heavily loaded. This can lead to degraded wifi
performance when running traffic at peak data rates.

A thread on the other hand can be moved to different
CPU cores, if the one on which its running is heavily
loaded. During high incoming data traffic, this gives
better performance, since the thread can be moved to a
less loaded or sometimes even a more powerful CPU core
to account for the required CPU performance in order
to process the incoming packets.

This patch series adds the support to use a high priority
thread to process the incoming packets, as opposed to
everything being done in NAPI context.

I don't see why this problem is limited to the ath10k driver. I expect
it applies to all drivers using NAPI. So shouldn't you be solving this
in the NAPI core? Allow a driver to request the NAPI core uses a
thread?

It's not just NAPI the problem is with the softint processing.
I suspect a lot of systems would work better if it ran as
a (highish priority) kernel thread.

Hi folks

Below is a minimunm poc implementation I can imagine on top of workqueue
to make napi threaded. Thoughts are appreciated.


I've had to remove the main locks from a multi-threaded application
and replace them with atomic counters.
Consider what happens when the threads remove items from a shared
work list.
The code looks like:
mutex_enter();
remove_item_from_list();
mutex_exit().
The mutex is only held for a few instructions, so while you'd expect
the cache line to be 'hot' you wouldn't get real contention.
However the following scenarios happen:
1) An ethernet interrupt happens while the mutex is held.
This stops the other threads until all the softint processing
has finished.
2) An ethernet interrupt (and softint) runs on a thread that is
waiting for the mutex.
(Or on the cpu that the thread's processor affinity ties it to.)
In this case the 'fair' (ticket) mutex code won't let any other
thread acquire the mutex.
So again everything stops until the softints all complete.

The second one is also a problem when trying to wake up all
the threads (eg after adding a lot of items to the list).
The ticket locks force them to wake in order, but
sometimes the 'thundering herd' would work better.

IIRC this is actually worse for processes running under the RT
scheduler (without CONFIG_PREEMPT) because the they are almost
always scheduled on the same cpu they ran on last.
If it is busy, but cannot be pre-empted, they are not moved
to an idle cpu.

To confound things there is a very broken workaround for broken

hardware in the driver for the e1000 interface on (at least)
Ivy Bridge cpu that can cause the driver to spin for a very
long time (IIRC milliseconds) whenever it has to write to a
MAC register (ie on every transmit setup).

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

To make napi threaded, if either irq or softirq thread is entirely ruled
out, add napi::work that will be queued on a highpri workqueue. It is
actually a unbound one to facilitate scheduler to catter napi loads on to
idle CPU cores. What users need to do with the threaded napi
is s/netif_napi_add/netif_threaded_napi_add/ and no more.

--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -338,6 +338,9 @@ struct napi_struct {
struct list_headdev_list;
struct hlist_node   napi_hash_node;
unsigned intnapi_id;
+#ifdef CONFIG_THREADED_NAPI
+   struct work_struct  work;
+#endif
  };
  
  enum {

@@ -2234,6 +2237,19 @@ static inline void *netdev_priv(const st
  void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
int (*poll)(struct napi_struct *, int), int weight);
  
+#ifdef CONFIG_THREADED_NAPI

+void netif_threaded_napi_add(struct net_device *dev, struct napi_struct *napi,
+   int (*poll)(struct napi_struct *, int), int weight);
+#else
+static inline void netif_threaded_napi_add(struct net_device *dev,
+   struct napi_struct *napi,
+   int 

Re: [RFC 7/7] ath10k: Handle rx thread suspend and resume

[Sebastian Gottschall]

your patch seem to only affect the WCN3990 chipset. all other ath10k 
supported chipset are not supported here. so you see a chance to 
implement this more generic?


Sebastian

Am 21.07.2020 um 19:14 schrieb Rakesh Pillai:

During the system suspend or resume, the rx thread
also needs to be suspended or resume respectively.

Handle the rx thread as well during the system
suspend and resume.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai 
---
  drivers/net/wireless/ath/ath10k/core.c | 23 ++
  drivers/net/wireless/ath/ath10k/core.h |  5 
  drivers/net/wireless/ath/ath10k/snoc.c | 44 +-
  3 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 4064fa2..b82b355 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -668,6 +668,27 @@ static unsigned int ath10k_core_get_fw_feature_str(char 
*buf,
return scnprintf(buf, buf_len, "%s", ath10k_core_fw_feature_str[feat]);
  }
  
+int ath10k_core_thread_suspend(struct ath10k_thread *thread)

+{
+   ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Suspending thread %s\n",
+  thread->name);
+   set_bit(ATH10K_THREAD_EVENT_SUSPEND, thread->event_flags);
+   wait_for_completion(>suspend);
+
+   return 0;
+}
+EXPORT_SYMBOL(ath10k_core_thread_suspend);
+
+int ath10k_core_thread_resume(struct ath10k_thread *thread)
+{
+   ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Resuming thread %s\n",
+  thread->name);
+   complete(>resume);
+
+   return 0;
+}
+EXPORT_SYMBOL(ath10k_core_thread_resume);
+
  void ath10k_core_thread_post_event(struct ath10k_thread *thread,
   enum ath10k_thread_events event)
  {
@@ -700,6 +721,8 @@ int ath10k_core_thread_init(struct ath10k *ar,
  
  	init_waitqueue_head(>wait_q);

init_completion(>shutdown);
+   init_completion(>suspend);
+   init_completion(>resume);
memcpy(thread->name, thread_name, ATH10K_THREAD_NAME_SIZE_MAX);
clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN, thread->event_flags);
ath10k_info(ar, "Starting thread %s\n", thread_name);
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 596d31b..df65e75 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -976,6 +976,7 @@ enum ath10k_thread_events {
ATH10K_THREAD_EVENT_SHUTDOWN,
ATH10K_THREAD_EVENT_RX_POST,
ATH10K_THREAD_EVENT_TX_POST,
+   ATH10K_THREAD_EVENT_SUSPEND,
ATH10K_THREAD_EVENT_MAX,
  };
  
@@ -983,6 +984,8 @@ struct ath10k_thread {

struct ath10k *ar;
struct task_struct *task;
struct completion shutdown;
+   struct completion suspend;
+   struct completion resume;
wait_queue_head_t wait_q;
DECLARE_BITMAP(event_flags, ATH10K_THREAD_EVENT_MAX);
char name[ATH10K_THREAD_NAME_SIZE_MAX];
@@ -1296,6 +1299,8 @@ static inline bool ath10k_peer_stats_enabled(struct 
ath10k *ar)
  
  extern unsigned long ath10k_coredump_mask;
  
+int ath10k_core_thread_suspend(struct ath10k_thread *thread);

+int ath10k_core_thread_resume(struct ath10k_thread *thread);
  void ath10k_core_thread_post_event(struct ath10k_thread *thread,
   enum ath10k_thread_events event);
  int ath10k_core_thread_shutdown(struct ath10k *ar,
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c 
b/drivers/net/wireless/ath/ath10k/snoc.c
index 3eb5eac..a373b2b 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -932,13 +932,31 @@ int ath10k_snoc_rx_thread_loop(void *data)
rx_thread->event_flags) ||
 test_and_clear_bit(ATH10K_THREAD_EVENT_TX_POST,
rx_thread->event_flags) ||
+test_bit(ATH10K_THREAD_EVENT_SUSPEND,
+ rx_thread->event_flags) ||
 test_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
  rx_thread->event_flags)));
  
+		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SUSPEND,

+  rx_thread->event_flags)) {
+   complete(_thread->suspend);
+   ath10k_info(ar, "rx thread suspend\n");
+   wait_for_completion(_thread->resume);
+   ath10k_info(ar, "rx thread resume\n");
+   }
+
ath10k_htt_txrx_compl_task(ar, thread_budget);
if (test_and_clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
   rx_thread->event_flags))
shutdown = true;
+
+   if (test_and_clear_bit(ATH10K_THREAD_EVENT_SUSPEND,
+ 

Re: [PATCH 4.14 00/78] 4.14.186-rc1 review

[Sebastian Gottschall]

this patch is broken. 4.14.186 has been already released. the patch 
shows just conflicts


Am 29.06.2020 um 17:36 schrieb Sasha Levin:

This is the start of the stable review cycle for the 4.14.186 release.
There are 78 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed 01 Jul 2020 03:38:04 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-4.14.y=v4.14.185

or in the git tree and branch at:
 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.14.y
and the diffstat can be found below.

--
Thanks,
Sasha

-

Pseudo-Shortlog of commits:

Aaron Plattner (1):
   ALSA: hda: Add NVIDIA codec IDs 9a & 9d through a0 to patch table

Aditya Pakki (1):
   rocker: fix incorrect error handling in dma_rings_init

Al Cooper (1):
   xhci: Fix enumeration issue when setting max packet size for FS
 devices.

Al Viro (1):
   fix a braino in "sparc32: fix register window handling in
 genregs32_[gs]et()"

Alexander Lobakin (3):
   net: qed: fix left elements count calculation
   net: qed: fix NVMe login fails over VFs
   net: qed: fix excessive QM ILT lines consumption

Chuck Lever (1):
   SUNRPC: Properly set the @subbuf parameter of xdr_buf_subsegment()

Chuhong Yuan (1):
   USB: ohci-sm501: Add missed iounmap() in remove

Dan Carpenter (2):
   usb: gadget: udc: Potential Oops in error handling code
   Staging: rtl8723bs: prevent buffer overflow in
 update_sta_support_rate()

David Christensen (1):
   tg3: driver sleeps indefinitely when EEH errors exceed eeh_max_freezes

David Howells (2):
   rxrpc: Fix notification call on completion of discarded calls
   rxrpc: Fix handling of rwind from an ACK packet

Denis Efremov (1):
   drm/radeon: fix fb_div check in ni_init_smc_spll_table()

Doug Berger (1):
   net: bcmgenet: use hardware padding of runt frames

Eric Dumazet (2):
   net: be more gentle about silly gso requests coming from user
   tcp: grow window for OOO packets only for SACK flows

Fan Guo (1):
   RDMA/mad: Fix possible memory leak in ib_mad_post_receive_mads()

Filipe Manana (1):
   btrfs: fix failure of RWF_NOWAIT write into prealloc extent beyond eof

Jann Horn (1):
   apparmor: don't try to replace stale label in ptraceme check

Jeremy Kerr (1):
   net: usb: ax88179_178a: fix packet alignment padding

Jiping Ma (1):
   arm64: perf: Report the PC value in REGS_ABI_32 mode

Joakim Tjernlund (1):
   cdc-acm: Add DISABLE_ECHO quirk for Microchip/SMSC chip

Julian Scheel (1):
   ALSA: usb-audio: uac1: Invalidate ctl on interrupt

Junxiao Bi (3):
   ocfs2: load global_inode_alloc
   ocfs2: fix value of OCFS2_INVALID_SLOT
   ocfs2: fix panic on nfs server over ocfs2

Juri Lelli (1):
   sched/core: Fix PI boosting between RT and DEADLINE tasks

Kai-Heng Feng (1):
   xhci: Poll for U0 after disabling USB2 LPM

Longfang Liu (1):
   USB: ehci: reopen solution for Synopsys HC bug

Luis Chamberlain (1):
   blktrace: break out of blktrace setup on concurrent calls

Macpaul Lin (1):
   usb: host: xhci-mtk: avoid runtime suspend when removing hcd

Marcelo Ricardo Leitner (1):
   sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket

Mark Zhang (1):
   RDMA/cma: Protect bind_list and listen_list while finding matching cm
 id

Martin Wilck (1):
   scsi: scsi_devinfo: handle non-terminated strings

Masahiro Yamada (1):
   kbuild: improve cc-option to clean up all temporary files

Masami Hiramatsu (1):
   tracing: Fix event trigger to accept redundant spaces

Mathias Nyman (1):
   xhci: Fix incorrect EP_STATE_MASK

Matthew Hagan (1):
   ARM: dts: NSP: Correct FA2 mailbox node

Minas Harutyunyan (1):
   usb: dwc2: Postponed gadget registration to the udc class driver

Nathan Chancellor (1):
   ACPI: sysfs: Fix pm_profile_attr type

Neal Cardwell (1):
   tcp_cubic: fix spurious HYSTART_DELAY exit upon drop in min RTT

Olga Kornievskaia (1):
   NFSv4 fix CLOSE not waiting for direct IO compeletion

Qiushi Wu (2):
   efi/esrt: Fix reference count leak in esre_create_sysfs_entry.
   ASoC: rockchip: Fix a reference count leak.

Russell King (1):
   netfilter: ipset: fix unaligned atomic access

Sasha Levin (1):
   Linux 4.14.186-rc1

Sean Christopherson (1):
   KVM: nVMX: Plumb L2 GPA through to PML emulation

Sven Schnelle (1):
   s390/ptrace: fix setting syscall number

Taehee Yoo (3):
   ip_tunnel: fix use-after-free in ip_tunnel_lookup()
   ip6_gre: fix use-after-free in ip6gre_tunnel_lookup()
   net: core: reduce recursion limit value

Takashi Iwai (3):
   ALSA: usb-audio: Clean up mixer element list traverse
   ALSA: usb-audio: Fix OOB access of mixer element list
   ALSA: usb-audio: Fix invalid NULL check in snd_emuusb_set_samplerate()

Tang Bin (1):
   

possible fix for broken cmac crypto support

[Sebastian Gottschall]

this is no real patch for this mailing list since i havent cloned yet a 
git tree. take it as a hint
this fixes the BUG WARN if SAE encryption is used (mandatory for mesh / 
802.11s crypto)
that will not fix that mesh is not working (likelly just with other 
vendors), but it will fix crypto at least


Sebastian

Index: main.c
===
--- main.c  (revision 4584)
+++ main.c  (revision 4585)
@@ -180,6 +180,20 @@ static int mt7615_set_key(struct ieee80211_hw *hw,
    !(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
    return -EOPNOTSUPP;

+   switch (key->cipher) {
+   case WLAN_CIPHER_SUITE_WEP40:
+   case WLAN_CIPHER_SUITE_WEP104:
+   case WLAN_CIPHER_SUITE_TKIP:
+   case WLAN_CIPHER_SUITE_CCMP:
+   case WLAN_CIPHER_SUITE_CCMP_256:
+   case WLAN_CIPHER_SUITE_GCMP:
+   case WLAN_CIPHER_SUITE_GCMP_256:
+   case WLAN_CIPHER_SUITE_SMS4:
+   break;
+   default:
+   return -EOPNOTSUPP;
+   }
+
    if (cmd == SET_KEY) {
    key->hw_key_idx = wcid->idx;
    wcid->hw_key_idx = idx;

Am 09.06.2019 um 16:36 schrieb Sebastian Gottschall:
by the way. this big fat kernel warning exists in all operation modes 
unless anything else but aes-128 ccmp is used. since the chipset is 
capable of doing gcmp etc. as well
it would be nice if this issue can be fixed. otherwise encryption 
support can be defined as "broken" for mt7615


Am 06.06.2019 um 18:19 schrieb Lorenzo Bianconi:

i tested your patch against a qca 9984 chipset using SAE and without
encryption. both did not work. the devices are connecting, but no data
connection is possible

Hi Sebastian,

I tested Ryder's patch using mt76x2 as mesh peer and it works fine 
for me.

Could you please provide some more info?

Regards,
Lorenzo



Sebastian

Am 03.06.2019 um 08:08 schrieb Ryder Lee:

Enable NL80211_IFTYPE_MESH_POINT and update its path.

Signed-off-by: Ryder Lee 
---
Changes since v3 - fix a wrong expression
Changes since v2 - remove unused definitions
---
   drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++
   drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
   drivers/net/wireless/mediatek/mt76/mt7615/mcu.c  | 4 +++-
   drivers/net/wireless/mediatek/mt76/mt7615/mcu.h  | 6 --
   4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/init.c

index 59f604f3161f..f860af6a42da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit 
if_limits[] = {

   {
   .max = MT7615_MAX_INTERFACES,
   .types = BIT(NL80211_IFTYPE_AP) |
+#ifdef CONFIG_MAC80211_MESH
+  BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
    BIT(NL80211_IFTYPE_STATION)
   }
   };
@@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
   dev->mt76.antenna_mask = 0xf;

   wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+#ifdef CONFIG_MAC80211_MESH
+ BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
    BIT(NL80211_IFTYPE_AP);

   ret = mt76_register_device(>mt76, true, mt7615_rates,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/main.c

index b0bb7cc12385..585e67fa2728 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, 
u32 mask)


   switch (type) {
   case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
   /* ap use hw bssid 0 and ext bssid */
   if (~mask & BIT(HW_BSSID_0))
   return HW_BSSID_0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c

index 43f70195244c..e82297048449 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev 
*dev,


   switch (vif->type) {
   case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
   tx_wlan_idx = mvif->sta.wcid.idx;
   conn_type = CONNECTION_INFRA_AP;
   break;
@@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, 
struct ieee80211_vif *vif,

   .rx_wtbl = {
   .tag = cpu_to_le16(WTBL_RX),
   .len = cpu_to_le16(sizeof(struct wtbl_rx)),
- .rca1 = vif->type != NL80211_IFTYPE_AP,
+ .rca1 = vif->type == NL80211_IFTYPE_STATION,
   .rca2 = 1,
   .rv = 

Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting

[Sebastian Gottschall]

okay. curious is, that my variant works with sane results too.
i will test your variant and check the results

Sebastian

Am 10.06.2019 um 06:22 schrieb Ryder Lee:

On Mon, 2019-06-10 at 10:09 +0800, Ryder Lee wrote:

On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:

according to my findings

MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
so it must be rxdg4 = rxd[4] etc.

RXV start from 1 in the code.

That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3


however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal 
calculation.
i already wrote a similar code for this driver which i sended to felix a long 
time ago.
my variant looks like
  status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) 
/ 2;
  status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 
220) / 2;
  status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 
220) / 2;
  status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 
220) / 2;
  status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 
220) / 2;

mt7615 actually doesn't use in-band RSSI for signal calculation, but it
occurs to me that i should modify the code to compare per-chain's
signal. Something like this:

status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
status->signal = status->chain_signal[0];

switch (status->chains) {
case 0xf:
status->signal = max(status->signal,
 status->chain_signal[3]);
case 0x7:
status->signal = max(status->signal,
 status->chain_signal[2]);
case 0x3:
status->signal = max(status->signal,
 status->chain_signal[1]);
break;
default:
break;
}


I could send a v2 or you can take care of that.

Ryder

Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting

[Sebastian Gottschall]

according to my findings

MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
so it must be rxdg4 = rxd[4] etc.
however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal 
calculation.
i already wrote a similar code for this driver which i sended to felix a long 
time ago.

my variant looks like
status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 
2;
status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 
220) / 2;
status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 
220) / 2;
status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 
220) / 2;
status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 
220) / 2;


Am 09.06.2019 um 11:09 schrieb Ryder Lee:

Fill in RX status->chain_signal to avoid empty value.

Signed-off-by: Ryder Lee 
---
  .../net/wireless/mediatek/mt76/mt7615/mac.c   | 30 ++-
  .../net/wireless/mediatek/mt76/mt7615/mac.h   |  5 
  2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index b60d42b5923d..9ee83ea11b8c
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -13,6 +13,11 @@
  #include "../dma.h"
  #include "mac.h"
  
+static inline s8 to_rssi(u32 field, u32 rxv)

+{
+   return (FIELD_GET(field, rxv) - 220) / 2;
+}
+
  static struct mt76_wcid *mt7615_rx_get_wcid(struct mt7615_dev *dev,
u8 idx, bool unicast)
  {
@@ -120,6 +125,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct 
sk_buff *skb)
if (rxd0 & MT_RXD0_NORMAL_GROUP_3) {
u32 rxdg0 = le32_to_cpu(rxd[0]);
u32 rxdg1 = le32_to_cpu(rxd[1]);
+   u32 rxdg3 = le32_to_cpu(rxd[3]);
u8 stbc = FIELD_GET(MT_RXV1_HT_STBC, rxdg0);
bool cck = false;
  
@@ -169,7 +175,29 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
  
  		status->enc_flags |= RX_ENC_FLAG_STBC_MASK * stbc;
  
-		/* TODO: RSSI */

+   status->chains = dev->mt76.antenna_mask;
+   status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
+   status->signal = status->chain_signal[0];
+
+   switch (status->chains) {
+   case 0x3:
+   status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
+   status->signal = max(status->signal,
+status->chain_signal[1]);
+   break;
+   case 0x7:
+   status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
+   status->signal = max(status->signal,
+status->chain_signal[2]);
+   break;
+   case 0xf:
+   status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
+   status->signal = max(status->signal,
+status->chain_signal[3]);
+   break;
+   default:
+   break;
+   }
rxd += 6;
if ((u8 *)rxd - skb->data >= skb->len)
return -EINVAL;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h 
b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
index 18ad4b8a3807..b00ce8db58e9
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
@@ -98,6 +98,11 @@ enum rx_pkt_type {
  #define MT_RXV2_GROUP_ID  GENMASK(26, 21)
  #define MT_RXV2_LENGTHGENMASK(20, 0)
  
+#define MT_RXV4_RCPI3			GENMASK(31, 24)

+#define MT_RXV4_RCPI2  GENMASK(23, 16)
+#define MT_RXV4_RCPI1  GENMASK(15, 8)
+#define MT_RXV4_RCPI0  GENMASK(7, 0)
+
  enum tx_header_format {
MT_HDR_FORMAT_802_3,
MT_HDR_FORMAT_CMD,

Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh

[Sebastian Gottschall]

by the way. this big fat kernel warning exists in all operation modes 
unless anything else but aes-128 ccmp is used. since the chipset is 
capable of doing gcmp etc. as well
it would be nice if this issue can be fixed. otherwise encryption 
support can be defined as "broken" for mt7615


Am 06.06.2019 um 18:19 schrieb Lorenzo Bianconi:

i tested your patch against a qca 9984 chipset using SAE and without
encryption. both did not work. the devices are connecting, but no data
connection is possible

Hi Sebastian,

I tested Ryder's patch using mt76x2 as mesh peer and it works fine for me.
Could you please provide some more info?

Regards,
Lorenzo



Sebastian

Am 03.06.2019 um 08:08 schrieb Ryder Lee:

Enable NL80211_IFTYPE_MESH_POINT and update its path.

Signed-off-by: Ryder Lee 
---
Changes since v3 - fix a wrong expression
Changes since v2 - remove unused definitions
---
   drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++
   drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
   drivers/net/wireless/mediatek/mt76/mt7615/mcu.c  | 4 +++-
   drivers/net/wireless/mediatek/mt76/mt7615/mcu.h  | 6 --
   4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 59f604f3161f..f860af6a42da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
   {
   .max = MT7615_MAX_INTERFACES,
   .types = BIT(NL80211_IFTYPE_AP) |
+#ifdef CONFIG_MAC80211_MESH
+  BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_STATION)
   }
   };
@@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
   dev->mt76.antenna_mask = 0xf;

   wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+#ifdef CONFIG_MAC80211_MESH
+  BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_AP);

   ret = mt76_register_device(>mt76, true, mt7615_rates,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index b0bb7cc12385..585e67fa2728 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)

   switch (type) {
   case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
   /* ap use hw bssid 0 and ext bssid */
   if (~mask & BIT(HW_BSSID_0))
   return HW_BSSID_0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 43f70195244c..e82297048449 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,

   switch (vif->type) {
   case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
   tx_wlan_idx = mvif->sta.wcid.idx;
   conn_type = CONNECTION_INFRA_AP;
   break;
@@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct 
ieee80211_vif *vif,
   .rx_wtbl = {
   .tag = cpu_to_le16(WTBL_RX),
   .len = cpu_to_le16(sizeof(struct wtbl_rx)),
- .rca1 = vif->type != NL80211_IFTYPE_AP,
+ .rca1 = vif->type == NL80211_IFTYPE_STATION,
   .rca2 = 1,
   .rv = 1,
   },
@@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype 
type, u32 *conn_type)
   {
   switch (type) {
   case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
   if (conn_type)
   *conn_type = CONNECTION_INFRA_STA;
   break;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
index e96efb13fa4d..0915cb735699 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
@@ -105,25 +105,19 @@ enum {
   #define STA_TYPE_STABIT(0)
   #define STA_TYPE_AP BIT(1)
   #define STA_TYPE_ADHOC  BIT(2)
-#define STA_TYPE_TDLSBIT(3)
   #define STA_TYPE_WDSBIT(4)
   #define STA_TYPE_BC BIT(5)

   #define NETWORK_INFRA   BIT(16)
   #define NETWORK_P2P BIT(17)
   #define NETWORK_IBSSBIT(18)
-#define NETWORK_MESH BIT(19)
-#define NETWORK_BOW  BIT(20)
   #define NETWORK_WDS BIT(21)

   #define CONNECTION_INFRA_STA(STA_TYPE_STA | NETWORK_INFRA)
   #define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
  

Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh

[Sebastian Gottschall]

Am 06.06.2019 um 18:19 schrieb Lorenzo Bianconi:

i tested your patch against a qca 9984 chipset using SAE and without
encryption. both did not work. the devices are connecting, but no data
connection is possible

Hi Sebastian,

I tested Ryder's patch using mt76x2 as mesh peer and it works fine for me.
Could you please provide some more info?


the peer was a QCA9984 chipset running ath10k. the following wpa 
supplicant config was used
and encryption clearly cannot work since mt76_wcid_key_setup does 
trigger a bug  since i_get_key_rx_seq does not accept tid as 
argument != 0 for aes_cmac (which is used for sae)
consider the same setup works with ath5k, 9k and 10k perfect with no 
issues. in my test setup i also connected now 3 devices. 2 9984 and 1 
mt7615 to ensure that all is working. the qca 9984 devices can ping each 
other, only the mt7615 does not work. the setups are all identical 
(except for ips)


fast_reauth=1
eapol_version=1
sae_groups=19 20 21
network={
    disable_ht40=1
    ssid="mt7615-24"
    mode=5
    frequency=2452
    htmode=HT20
    scan_ssid=1
    key_mgmt=SAE
    ieee80211w=2
    noscan=1
    pairwise=CCMP
    group=CCMP
    proto=RSN
    sae_password="12345678"
}

and the bug again

WARNING: CPU: 2 PID: 22086 at 
/home/seg/DEV/mt7621/src/router/private/compat-wireless-2017-09-03/net/mac80211/key.c:1096 
mt76_wcid_key_setup+0x58/0x9c [mt76]
Modules linked in: shortcut_fe gcm ghash_generic ctr gf128mul mt7615e 
mt76 mac80211 compat

CPU: 2 PID: 22086 Comm: wpa_supplicant Tainted: G    W 4.14.123 #106
Stack :  87c2d000  8007d8b4 8048 80482b9c 8061 
805a4390
    8057e2b4 87c4b99c 870a59dc 805e4767 80578288 0001 87c4b940 
805e9f78
      8064  81147bb8 06ce 0007 

     8065 8065 20202020 8000  8061 
872b9fe0
    872a2b14 0448  87c2d000 0010 8022d660 0008 
80640008

    ...
Call Trace:
[<800153e0>] show_stack+0x58/0x100
[<8042e83c>] dump_stack+0x9c/0xe0
[<800349f0>] __warn+0xe4/0x144
[<8003468c>] warn_slowpath_null+0x1c/0x30
[<872b9fe0>] mt76_wcid_key_setup+0x58/0x9c [mt76]
[<87611690>] mt7615_eeprom_init+0x7b4/0xe9c [mt7615e]
---[ end trace e24aeb4b542e0df9 ]---




Regards,
Lorenzo



Sebastian

Am 03.06.2019 um 08:08 schrieb Ryder Lee:

Enable NL80211_IFTYPE_MESH_POINT and update its path.

Signed-off-by: Ryder Lee 
---
Changes since v3 - fix a wrong expression
Changes since v2 - remove unused definitions
---
   drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++
   drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
   drivers/net/wireless/mediatek/mt76/mt7615/mcu.c  | 4 +++-
   drivers/net/wireless/mediatek/mt76/mt7615/mcu.h  | 6 --
   4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 59f604f3161f..f860af6a42da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
   {
   .max = MT7615_MAX_INTERFACES,
   .types = BIT(NL80211_IFTYPE_AP) |
+#ifdef CONFIG_MAC80211_MESH
+  BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_STATION)
   }
   };
@@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
   dev->mt76.antenna_mask = 0xf;

   wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+#ifdef CONFIG_MAC80211_MESH
+  BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_AP);

   ret = mt76_register_device(>mt76, true, mt7615_rates,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index b0bb7cc12385..585e67fa2728 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)

   switch (type) {
   case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
   /* ap use hw bssid 0 and ext bssid */
   if (~mask & BIT(HW_BSSID_0))
   return HW_BSSID_0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 43f70195244c..e82297048449 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,

   switch (vif->type) {
   case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
   tx_wlan_idx = mvif->sta.wcid.idx;
   conn_type = CONNECTION_INFRA_AP;
   break;

Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh

[Sebastian Gottschall]

in addition you should take care about this problem which is raised up 
if SAE is used. since AES-CMAC required tid to be non zero


WARNING: CPU: 2 PID: 15324 at 
/home/seg/DEV/mt7621/src/router/private/compat-wireless-2017-09-03/net/mac80211/key.c:1096 
mt76_wcid_key_setup+0x58/0x9c [mt76]
Modules linked in: shortcut_fe gcm ghash_generic ctr gf128mul mt7615e 
mt76 mac80211 compat

CPU: 2 PID: 15324 Comm: wpa_supplicant Tainted: G    W 4.14.123 #106
Stack :  87c2d000  8007d8b4 8048 80482b9c 8061 
805a4390
    8057e2b4 854fb99c 87ed045c 805e4767 80578288 0001 854fb940 
805e9f78
      8064  81147bb8 0584 0007 

     8065 8065 20202020 8000  8061 
872b9fe0
    872a2b14 0448  87c2d000 0010 8022d660 0008 
80640008

    ...
Call Trace:
[<800153e0>] show_stack+0x58/0x100
[<8042e83c>] dump_stack+0x9c/0xe0
[<800349f0>] __warn+0xe4/0x144
[<8003468c>] warn_slowpath_null+0x1c/0x30
[<872b9fe0>] mt76_wcid_key_setup+0x58/0x9c [mt76]
[<87611690>] mt7615_eeprom_init+0x7b4/0xe9c [mt7615e]
---[ end trace e24aeb4b542e0dea ]---

Am 03.06.2019 um 08:08 schrieb Ryder Lee:

Enable NL80211_IFTYPE_MESH_POINT and update its path.

Signed-off-by: Ryder Lee 
---
Changes since v3 - fix a wrong expression
Changes since v2 - remove unused definitions
---
  drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++
  drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
  drivers/net/wireless/mediatek/mt76/mt7615/mcu.c  | 4 +++-
  drivers/net/wireless/mediatek/mt76/mt7615/mcu.h  | 6 --
  4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 59f604f3161f..f860af6a42da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
{
.max = MT7615_MAX_INTERFACES,
.types = BIT(NL80211_IFTYPE_AP) |
+#ifdef CONFIG_MAC80211_MESH
+BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
 BIT(NL80211_IFTYPE_STATION)
}
  };
@@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
dev->mt76.antenna_mask = 0xf;
  
  	wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |

+#ifdef CONFIG_MAC80211_MESH
+BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
 BIT(NL80211_IFTYPE_AP);
  
  	ret = mt76_register_device(>mt76, true, mt7615_rates,

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index b0bb7cc12385..585e67fa2728 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
  
  	switch (type) {

case NL80211_IFTYPE_AP:
+   case NL80211_IFTYPE_MESH_POINT:
/* ap use hw bssid 0 and ext bssid */
if (~mask & BIT(HW_BSSID_0))
return HW_BSSID_0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 43f70195244c..e82297048449 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
  
  	switch (vif->type) {

case NL80211_IFTYPE_AP:
+   case NL80211_IFTYPE_MESH_POINT:
tx_wlan_idx = mvif->sta.wcid.idx;
conn_type = CONNECTION_INFRA_AP;
break;
@@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct 
ieee80211_vif *vif,
.rx_wtbl = {
.tag = cpu_to_le16(WTBL_RX),
.len = cpu_to_le16(sizeof(struct wtbl_rx)),
-   .rca1 = vif->type != NL80211_IFTYPE_AP,
+   .rca1 = vif->type == NL80211_IFTYPE_STATION,
.rca2 = 1,
.rv = 1,
},
@@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype 
type, u32 *conn_type)
  {
switch (type) {
case NL80211_IFTYPE_AP:
+   case NL80211_IFTYPE_MESH_POINT:
if (conn_type)
*conn_type = CONNECTION_INFRA_STA;
break;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
index e96efb13fa4d..0915cb735699 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
@@ -105,25 +105,19 @@ enum {
  #define STA_TYPE_STA  BIT(0)
  #define STA_TYPE_AP   BIT(1)
  #define STA_TYPE_ADHOC 

Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh

[Sebastian Gottschall]

i tested your patch against a qca 9984 chipset using SAE and without 
encryption. both did not work. the devices are connecting, but no data 
connection is possible



Sebastian

Am 03.06.2019 um 08:08 schrieb Ryder Lee:

Enable NL80211_IFTYPE_MESH_POINT and update its path.

Signed-off-by: Ryder Lee 
---
Changes since v3 - fix a wrong expression
Changes since v2 - remove unused definitions
---
  drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++
  drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
  drivers/net/wireless/mediatek/mt76/mt7615/mcu.c  | 4 +++-
  drivers/net/wireless/mediatek/mt76/mt7615/mcu.h  | 6 --
  4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 59f604f3161f..f860af6a42da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
{
.max = MT7615_MAX_INTERFACES,
.types = BIT(NL80211_IFTYPE_AP) |
+#ifdef CONFIG_MAC80211_MESH
+BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
 BIT(NL80211_IFTYPE_STATION)
}
  };
@@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
dev->mt76.antenna_mask = 0xf;
  
  	wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |

+#ifdef CONFIG_MAC80211_MESH
+BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
 BIT(NL80211_IFTYPE_AP);
  
  	ret = mt76_register_device(>mt76, true, mt7615_rates,

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index b0bb7cc12385..585e67fa2728 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
  
  	switch (type) {

case NL80211_IFTYPE_AP:
+   case NL80211_IFTYPE_MESH_POINT:
/* ap use hw bssid 0 and ext bssid */
if (~mask & BIT(HW_BSSID_0))
return HW_BSSID_0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 43f70195244c..e82297048449 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
  
  	switch (vif->type) {

case NL80211_IFTYPE_AP:
+   case NL80211_IFTYPE_MESH_POINT:
tx_wlan_idx = mvif->sta.wcid.idx;
conn_type = CONNECTION_INFRA_AP;
break;
@@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct 
ieee80211_vif *vif,
.rx_wtbl = {
.tag = cpu_to_le16(WTBL_RX),
.len = cpu_to_le16(sizeof(struct wtbl_rx)),
-   .rca1 = vif->type != NL80211_IFTYPE_AP,
+   .rca1 = vif->type == NL80211_IFTYPE_STATION,
.rca2 = 1,
.rv = 1,
},
@@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype 
type, u32 *conn_type)
  {
switch (type) {
case NL80211_IFTYPE_AP:
+   case NL80211_IFTYPE_MESH_POINT:
if (conn_type)
*conn_type = CONNECTION_INFRA_STA;
break;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
index e96efb13fa4d..0915cb735699 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
@@ -105,25 +105,19 @@ enum {
  #define STA_TYPE_STA  BIT(0)
  #define STA_TYPE_AP   BIT(1)
  #define STA_TYPE_ADHOCBIT(2)
-#define STA_TYPE_TDLS  BIT(3)
  #define STA_TYPE_WDS  BIT(4)
  #define STA_TYPE_BC   BIT(5)
  
  #define NETWORK_INFRA		BIT(16)

  #define NETWORK_P2P   BIT(17)
  #define NETWORK_IBSS  BIT(18)
-#define NETWORK_MESH   BIT(19)
-#define NETWORK_BOWBIT(20)
  #define NETWORK_WDS   BIT(21)
  
  #define CONNECTION_INFRA_STA	(STA_TYPE_STA | NETWORK_INFRA)

  #define CONNECTION_INFRA_AP   (STA_TYPE_AP | NETWORK_INFRA)
  #define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
  #define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
-#define CONNECTION_MESH_STA(STA_TYPE_STA | NETWORK_MESH)
-#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
  #define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
-#define CONNECTION_TDLS(STA_TYPE_STA | NETWORK_INFRA | 
STA_TYPE_TDLS)
  #define CONNECTION_WDS(STA_TYPE_WDS | NETWORK_WDS)
  #define 

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Sebastian Gottschall]

Am 07.05.2019 um 12:31 schrieb David Laight:

...

So I don't really see a problem with Andy's patch. If we want to annoy
external non-GPL modules as much as possible, sure, that's for a separate
discussion though (and I am sure many people would agree to that).
Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would
be a good start I guess :)

As a writer on an external non-GPL module I'd point out:
1 - Even if we wanted to 'upstream' our code it is very specific
 and wouldn't really be wanted/accepted.
 Even if accepted it would always be excluded from builds.
2 - It would take man-years to make it meet the kernel code guidelines
 and to make it portable (from x86).
 It also contains conditionals because it gets build for windows.
 I don't like a lot of it.
3 - Almost all the calls to kernel functions are through a 'wrapper'
 file that is compiled on the target system.
 About the only functions that are directly called are ones like memcpy().
4 - It wouldn't be that hard, and would still be GPLv2 if we built
 two loadable modules, one GPL and one non-GPL and put all our
 wrapper functions in the GPL one.
 We'd still need a small wrapper for the non-GPL module, but while
 Non-GPL modules are supported at all it wouldn't be much work.
5 - The continual tweaks for new kernel versions keep us in a job!

Some of the _GPL exports are a PITA:
- we can't reference count network namespaces (without creating a socket).
- we can't reference count 'pid' structures making sending signals tricky.
- I thing the PCIe error handling functions that we ought to be using
   are GPL.

At the moment we've not needed the fpu :-)

David
unfortunatly some does like ZFS which is opensource, but just licensed 
under the wrong copyleft license which cannot be changed that easy.
but its a big loss for the community if such projects get blocked or 
limited by a singe linux developer. but thats just my own oppinion (even 
if not intentionally targeted here of course).
not every project on his planet is a nvidia driver blob. whats most 
important for me is not if its GPL or not. most important is that its 
opensource and copyleft.
so the question is if it isnt possible to create a EXPORT_SYMBOL variant 
which includes acceptable license models, but still restricts 
unacceptable licenses


Sebastian

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Sebastian Gottschall]

Am 04.05.2019 um 02:47 schrieb Ingo Molnar:

* Jiri Kosina  wrote:


On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:


Please don't start this. We have everything _GPL that is used for FPU
related code and only a few functions are exported because KVM needs it.

That's not completely true. There are a lot of static inlines out there,
which basically made it possible for external modules to use FPU (in some
way) when they had kernel_fpu_[begin|end]() available.

I personally don't care about ZFS a tiny little bit; but in general, the
current situation with _GPL and non-_GPL exports is simply not nice. It's
not really about licensing (despite the name), it's about 'internal vs
external', which noone is probably able to define properly.

But that's exactly what licensing *IS* about: the argument is that
'internal' interfaces are clear proof that the binary module is actually
a derived work of the kernel.
Using fpu code in kernel space in a kernel module is a derived work of 
the kernel itself?
dont get me wrong, but this is absurd. i mean you limit the use of cpu 
instructions. the use
of cpu instructions should be free of any licensing issue. i would even 
argument you are violating
the license of the cpu ower given to the kernel by executing it, by 
restricting its use for no reason



Sebastian

Re: [PATCH 4.19 01/24] bridge: do not add port to router list when receives query with source 0.0.0.0

[Sebastian Gottschall]

Am 20.02.2019 um 15:46 schrieb Hangbin Liu:

Could you please include more details about the setup that's broken ?
Note that we were warned[1] of potential breakage from this change

Sorry I missed Linus's reply after Ying Xu replied. I will read it and
disscuss with Ying Xu.


after it went in and regardless of the suggestion from the RFC we'll
probably have to revert this patch.

Ying Xu as author of the patch, any thoughts ?

No, we are also waiting for more details from Sebastian.


the test scenario is the following. one of my testers of the dd-wrt 
firmware is using a iptv stream from the france isp "orange".
he just bridged the iptv vlan interface which has no ip (the isp doesnt 
provide a ip configuration here) to a bridge and played with igmp 
snooping to avoid flooding of all ports within the same bridge.
he found out that this setting simply does not work with the current 
kernel, but does
if this patch has been removed. we used kernel 4.4 in the test scenario. 
all latest revision.
i was able to reproduce the same problem on kernel 4.9 and 4.14 on a 
different device using a german isp based iptv stream. same effect. 
after reverting the problematic code it worked again.


Sebastian



Thanks
Hangbin


Also adding Linus Lüssing to the CC as he was the one who warned against it.
Note that the warning was sent as a reply to my breakage fix, but it was 
intended
for the original patch.

Thanks,
  Nik

[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg272944.html

Re: [PATCH 4.19 01/24] bridge: do not add port to router list when receives query with source 0.0.0.0

[Sebastian Gottschall]

*reminder*

Am 18.02.2019 um 11:18 schrieb Sebastian Gottschall:


Am 17.02.2019 um 17:48 schrieb Greg Kroah-Hartman:

On Sun, Feb 17, 2019 at 03:29:22PM +0100, Sebastian Gottschall wrote:
according to user reports this patch will cause a serious 
regression. igmp

snooping is not working anymore with this patch

Am 02.11.2018 um 19:34 schrieb Greg Kroah-Hartman:
4.19-stable review patch.  If anyone has any objections, please let 
me know.


--

From: Hangbin Liu 

[ Upstream commit 5a2de63fd1a59c30c02526d427bc014b98adf508 ]

Based on RFC 4541, 2.1.1.  IGMP Forwarding Rules

    The switch supporting IGMP snooping must maintain a list of
    multicast routers and the ports on which they are attached.  This
    list can be constructed in any combination of the following ways:

    a) This list should be built by the snooping switch sending
   Multicast Router Solicitation messages as described in IGMP
   Multicast Router Discovery [MRDISC].  It may also snoop
   Multicast Router Advertisement messages sent by and to other
   nodes.

    b) The arrival port for IGMP Queries (sent by multicast routers)
   where the source address is not 0.0.0.0.

We should not add the port to router list when receives query with 
source

0.0.0.0.

Reported-by: Ying Xu 
Signed-off-by: Hangbin Liu 
Acked-by: Nikolay Aleksandrov 
Acked-by: Roopa Prabhu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
   net/bridge/br_multicast.c |   10 +-
   1 file changed, 9 insertions(+), 1 deletion(-)

--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1420,7 +1420,15 @@ static void br_multicast_query_received(
   return;
   br_multicast_update_query_timer(br, query, max_delay);
-    br_multicast_mark_router(br, port);
+
+    /* Based on RFC4541, section 2.1.1 IGMP Forwarding Rules,
+ * the arrival port for IGMP Queries where the source address
+ * is 0.0.0.0 should not be added to router port list.
+ */
+    if ((saddr->proto == htons(ETH_P_IP) && saddr->u.ip4) ||
+    (saddr->proto == htons(ETH_P_IPV6) &&
+ !ipv6_addr_any(>u.ip6)))
+    br_multicast_mark_router(br, port);
   }
   static void br_ip4_multicast_query(struct net_bridge *br,

Is this also a problem in 4.20?  This patch went into 4.20-rc1, so it
has been around for a while with no reported issues that I can find.
Any pointers to the reports?


i need to check this. i found this patch in 4.9, 4.14 and 4.4
the rest was picked up from the mailinglist. according to the git 
sources of 4.20 and 5.0 the same code is in there as well


i just got the report from users today and was able to reproduce it 
with iptv streams. just by disabling the code it was working again.


Sebastian


thanks,

greg k-h

Re: [PATCH 4.19 01/24] bridge: do not add port to router list when receives query with source 0.0.0.0

[Sebastian Gottschall]

Am 17.02.2019 um 17:48 schrieb Greg Kroah-Hartman:

On Sun, Feb 17, 2019 at 03:29:22PM +0100, Sebastian Gottschall wrote:
according to user reports this patch will cause a serious regression. 
igmp

snooping is not working anymore with this patch

Am 02.11.2018 um 19:34 schrieb Greg Kroah-Hartman:
4.19-stable review patch.  If anyone has any objections, please let 
me know.


--

From: Hangbin Liu 

[ Upstream commit 5a2de63fd1a59c30c02526d427bc014b98adf508 ]

Based on RFC 4541, 2.1.1.  IGMP Forwarding Rules

    The switch supporting IGMP snooping must maintain a list of
    multicast routers and the ports on which they are attached.  This
    list can be constructed in any combination of the following ways:

    a) This list should be built by the snooping switch sending
   Multicast Router Solicitation messages as described in IGMP
   Multicast Router Discovery [MRDISC].  It may also snoop
   Multicast Router Advertisement messages sent by and to other
   nodes.

    b) The arrival port for IGMP Queries (sent by multicast routers)
   where the source address is not 0.0.0.0.

We should not add the port to router list when receives query with 
source

0.0.0.0.

Reported-by: Ying Xu 
Signed-off-by: Hangbin Liu 
Acked-by: Nikolay Aleksandrov 
Acked-by: Roopa Prabhu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
   net/bridge/br_multicast.c |   10 +-
   1 file changed, 9 insertions(+), 1 deletion(-)

--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1420,7 +1420,15 @@ static void br_multicast_query_received(
   return;
   br_multicast_update_query_timer(br, query, max_delay);
-    br_multicast_mark_router(br, port);
+
+    /* Based on RFC4541, section 2.1.1 IGMP Forwarding Rules,
+ * the arrival port for IGMP Queries where the source address
+ * is 0.0.0.0 should not be added to router port list.
+ */
+    if ((saddr->proto == htons(ETH_P_IP) && saddr->u.ip4) ||
+    (saddr->proto == htons(ETH_P_IPV6) &&
+ !ipv6_addr_any(>u.ip6)))
+    br_multicast_mark_router(br, port);
   }
   static void br_ip4_multicast_query(struct net_bridge *br,

Is this also a problem in 4.20?  This patch went into 4.20-rc1, so it
has been around for a while with no reported issues that I can find.
Any pointers to the reports?


i need to check this. i found this patch in 4.9, 4.14 and 4.4
the rest was picked up from the mailinglist. according to the git 
sources of 4.20 and 5.0 the same code is in there as well


i just got the report from users today and was able to reproduce it with 
iptv streams. just by disabling the code it was working again.


Sebastian


thanks,

greg k-h

Re: [PATCH 4.19 01/24] bridge: do not add port to router list when receives query with source 0.0.0.0

[Sebastian Gottschall]

according to user reports this patch will cause a serious regression. 
igmp snooping is not working anymore with this patch


Am 02.11.2018 um 19:34 schrieb Greg Kroah-Hartman:

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Hangbin Liu 

[ Upstream commit 5a2de63fd1a59c30c02526d427bc014b98adf508 ]

Based on RFC 4541, 2.1.1.  IGMP Forwarding Rules

   The switch supporting IGMP snooping must maintain a list of
   multicast routers and the ports on which they are attached.  This
   list can be constructed in any combination of the following ways:

   a) This list should be built by the snooping switch sending
  Multicast Router Solicitation messages as described in IGMP
  Multicast Router Discovery [MRDISC].  It may also snoop
  Multicast Router Advertisement messages sent by and to other
  nodes.

   b) The arrival port for IGMP Queries (sent by multicast routers)
  where the source address is not 0.0.0.0.

We should not add the port to router list when receives query with source
0.0.0.0.

Reported-by: Ying Xu 
Signed-off-by: Hangbin Liu 
Acked-by: Nikolay Aleksandrov 
Acked-by: Roopa Prabhu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
  net/bridge/br_multicast.c |   10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1420,7 +1420,15 @@ static void br_multicast_query_received(
return;
  
  	br_multicast_update_query_timer(br, query, max_delay);

-   br_multicast_mark_router(br, port);
+
+   /* Based on RFC4541, section 2.1.1 IGMP Forwarding Rules,
+* the arrival port for IGMP Queries where the source address
+* is 0.0.0.0 should not be added to router port list.
+*/
+   if ((saddr->proto == htons(ETH_P_IP) && saddr->u.ip4) ||
+   (saddr->proto == htons(ETH_P_IPV6) &&
+!ipv6_addr_any(>u.ip6)))
+   br_multicast_mark_router(br, port);
  }
  
  static void br_ip4_multicast_query(struct net_bridge *br,

Re: [PATCH 4.4 00/48] 4.4.162-stable review

[Sebastian Gottschall]

4.4, 4.9 and 4.14 contain a new file named 
arch/riscv/include/asm/asm-prototypes.h


this doesnt seem to belong to these kernels since arch/riscv was not 
even present before



Sebastian

Am 18.10.2018 um 19:54 schrieb Greg Kroah-Hartman:

This is the start of the stable review cycle for the 4.4.162 release.
There are 48 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Oct 20 17:54:03 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.162-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
 Linux 4.4.162-rc1

Long Li 
 HV: properly delay KVP packets when negotiation is in progress

Vitaly Kuznetsov 
 Drivers: hv: kvp: fix IP Failover

K. Y. Srinivasan 
 Drivers: hv: util: Pass the channel information during the init call

K. Y. Srinivasan 
 Drivers: hv: utils: Invoke the poll function after handshake

Stephen Warren 
 usb: gadget: serial: fix oops when data rx'd after close

Alexey Brodkin 
 ARC: build: Get rid of toolchain check

Michael Neuling 
 powerpc/tm: Avoid possible userspace r1 corruption on reclaim

Michael Neuling 
 powerpc/tm: Fix userspace r13 corruption

James Cowgill 
 RISC-V: include linux/ftrace.h in asm-prototypes.h

Nathan Chancellor 
 net/mlx4: Use cpumask_available for eq->affinity_mask

Michael Schmitz 
 Input: atakbd - fix Atari CapsLock behaviour

Andreas Schwab 
 Input: atakbd - fix Atari keymap

Keerthy 
 clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for 
non-am43 SoCs

Jozef Balga 
 media: af9035: prevent buffer overflow on write

Andy Lutomirski 
 x86/fpu: Finish excising 'eagerfpu'

Rik van Riel 
 x86/fpu: Remove struct fpu::counter

Andy Lutomirski 
 x86/fpu: Remove use_eager_fpu()

Paolo Bonzini 
 KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch

Eric Dumazet 
 rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096

Florian Fainelli 
 net: systemport: Fix wake-up interrupt race during resume

Maxime Chevallier 
 net: mvpp2: Extract the correct ethtype from the skb for tx csum offload

Ido Schimmel 
 team: Forbid enslaving team device to itself

Shahed Shaikh 
 qlcnic: fix Tx descriptor corruption on 82xx devices

Yu Zhao 
 net/usb: cancel pending work when unbinding smsc75xx

Sean Tranchetti 
 netlabel: check for IPV4MASK in addrinfo_get

Jeff Barnhill <0xeff...@gmail.com>
 net/ipv6: Display all addresses in output of /proc/net/if_inet6

Sabrina Dubroca 
 net: ipv4: update fnhe_pmtu when first hop's MTU changes

Eric Dumazet 
 ipv4: fix use-after-free in ip_cmsg_recv_dstaddr()

Paolo Abeni 
 ip_tunnel: be careful when accessing the inner header

Paolo Abeni 
 ip6_tunnel: be careful when accessing the inner header

Mahesh Bandewar 
 bonding: avoid possible dead-lock

Michael Chan 
 bnxt_en: Fix TX timeout during netpoll.

Hou Tao 
 jffs2: return -ERANGE when xattr buffer is too small

Mathias Nyman 
 xhci: Don't print a warning when setting link state for disabled ports

Edgar Cherkasov 
 i2c: i2c-scmi: fix for i2c_smbus_write_block_data

Adrian Hunter 
 perf script python: Fix export-to-postgresql.py occasional failure

Mikulas Patocka 
 mach64: detect the dot clock divider correctly on sparc

Jann Horn 
 mm/vmstat.c: fix outdated vmstat_text

Theodore Ts'o 
 ext4: add corruption check in ext4_xattr_set_entry()

Amber Lin 
 drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7

Nicolas Ferre 
 ARM: dts: at91: add new compatibility string for macb on sama5d3

Nicolas Ferre 
 net: macb: disable scatter-gather for macb on sama5d3

Jongsung Kim 
 stmmac: fix valid numbers of unicast filter entries

Yu Zhao 
 sound: enable interrupt after dma buffer initialization

Tony Lindgren 
 mfd: omap-usb-host: Fix dts probe of children

Lei Yang 
 selftests/efivarfs: add required kernel configs

Danny Smith 
 ASoC: sigmadsp: safeload should not have lower byte limit

Pierre-Louis Bossart 
 ASoC: wm8804: Add ACPI support


-

Diffstat:

  Documentation/devicetree/bindings/net/macb.txt |  1 +
  Documentation/kernel-parameters.txt|  5 --
  Makefile   |  4 +-
  arch/arc/Makefile  | 14 
  arch/arm/boot/dts/sama5d3_emac.dtsi|  2 +-
  arch/powerpc/kernel/tm.S   | 20 +-
  arch/riscv/include/asm/asm-prototypes.h|  7 ++
  

Re: [PATCH 4.4 00/48] 4.4.162-stable review

[Sebastian Gottschall]

4.4, 4.9 and 4.14 contain a new file named 
arch/riscv/include/asm/asm-prototypes.h


this doesnt seem to belong to these kernels since arch/riscv was not 
even present before



Sebastian

Am 18.10.2018 um 19:54 schrieb Greg Kroah-Hartman:

This is the start of the stable review cycle for the 4.4.162 release.
There are 48 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Oct 20 17:54:03 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.162-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
 Linux 4.4.162-rc1

Long Li 
 HV: properly delay KVP packets when negotiation is in progress

Vitaly Kuznetsov 
 Drivers: hv: kvp: fix IP Failover

K. Y. Srinivasan 
 Drivers: hv: util: Pass the channel information during the init call

K. Y. Srinivasan 
 Drivers: hv: utils: Invoke the poll function after handshake

Stephen Warren 
 usb: gadget: serial: fix oops when data rx'd after close

Alexey Brodkin 
 ARC: build: Get rid of toolchain check

Michael Neuling 
 powerpc/tm: Avoid possible userspace r1 corruption on reclaim

Michael Neuling 
 powerpc/tm: Fix userspace r13 corruption

James Cowgill 
 RISC-V: include linux/ftrace.h in asm-prototypes.h

Nathan Chancellor 
 net/mlx4: Use cpumask_available for eq->affinity_mask

Michael Schmitz 
 Input: atakbd - fix Atari CapsLock behaviour

Andreas Schwab 
 Input: atakbd - fix Atari keymap

Keerthy 
 clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for 
non-am43 SoCs

Jozef Balga 
 media: af9035: prevent buffer overflow on write

Andy Lutomirski 
 x86/fpu: Finish excising 'eagerfpu'

Rik van Riel 
 x86/fpu: Remove struct fpu::counter

Andy Lutomirski 
 x86/fpu: Remove use_eager_fpu()

Paolo Bonzini 
 KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch

Eric Dumazet 
 rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096

Florian Fainelli 
 net: systemport: Fix wake-up interrupt race during resume

Maxime Chevallier 
 net: mvpp2: Extract the correct ethtype from the skb for tx csum offload

Ido Schimmel 
 team: Forbid enslaving team device to itself

Shahed Shaikh 
 qlcnic: fix Tx descriptor corruption on 82xx devices

Yu Zhao 
 net/usb: cancel pending work when unbinding smsc75xx

Sean Tranchetti 
 netlabel: check for IPV4MASK in addrinfo_get

Jeff Barnhill <0xeff...@gmail.com>
 net/ipv6: Display all addresses in output of /proc/net/if_inet6

Sabrina Dubroca 
 net: ipv4: update fnhe_pmtu when first hop's MTU changes

Eric Dumazet 
 ipv4: fix use-after-free in ip_cmsg_recv_dstaddr()

Paolo Abeni 
 ip_tunnel: be careful when accessing the inner header

Paolo Abeni 
 ip6_tunnel: be careful when accessing the inner header

Mahesh Bandewar 
 bonding: avoid possible dead-lock

Michael Chan 
 bnxt_en: Fix TX timeout during netpoll.

Hou Tao 
 jffs2: return -ERANGE when xattr buffer is too small

Mathias Nyman 
 xhci: Don't print a warning when setting link state for disabled ports

Edgar Cherkasov 
 i2c: i2c-scmi: fix for i2c_smbus_write_block_data

Adrian Hunter 
 perf script python: Fix export-to-postgresql.py occasional failure

Mikulas Patocka 
 mach64: detect the dot clock divider correctly on sparc

Jann Horn 
 mm/vmstat.c: fix outdated vmstat_text

Theodore Ts'o 
 ext4: add corruption check in ext4_xattr_set_entry()

Amber Lin 
 drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7

Nicolas Ferre 
 ARM: dts: at91: add new compatibility string for macb on sama5d3

Nicolas Ferre 
 net: macb: disable scatter-gather for macb on sama5d3

Jongsung Kim 
 stmmac: fix valid numbers of unicast filter entries

Yu Zhao 
 sound: enable interrupt after dma buffer initialization

Tony Lindgren 
 mfd: omap-usb-host: Fix dts probe of children

Lei Yang 
 selftests/efivarfs: add required kernel configs

Danny Smith 
 ASoC: sigmadsp: safeload should not have lower byte limit

Pierre-Louis Bossart 
 ASoC: wm8804: Add ACPI support


-

Diffstat:

  Documentation/devicetree/bindings/net/macb.txt |  1 +
  Documentation/kernel-parameters.txt|  5 --
  Makefile   |  4 +-
  arch/arc/Makefile  | 14 
  arch/arm/boot/dts/sama5d3_emac.dtsi|  2 +-
  arch/powerpc/kernel/tm.S   | 20 +-
  arch/riscv/include/asm/asm-prototypes.h|  7 ++
  

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 22:42 schrieb Linus Torvalds:


It would definitely be helpful, since I'm already quite busy with the
normal merge window work. Having the embargo for L1TF end just as the
merge window opened wasn't all that convenient.


all good so far. i checked them all and i will see how my nightly build 
goes out which does compilation on alot of

mips, arm, powerpc etc. platforms



Of course, I have my own "I will delay 4.18 by a week" to blame for the timing.

So if you can find the places that break, and add the right header,
and send me a patch for all the ones you find, that would be lovely.

will do so. but for now it seems that this was really the only one


It's not necessarilky always  or  that makes
sense to add as an include. As mentioned, sometimes it's
 or similar.


mmh why? i prefer to include the correct header which references the 
function or macro instead of adding
a header which finds the right way by multiple iterations. its more 
transparent



Sebastian

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 22:42 schrieb Linus Torvalds:


It would definitely be helpful, since I'm already quite busy with the
normal merge window work. Having the embargo for L1TF end just as the
merge window opened wasn't all that convenient.


all good so far. i checked them all and i will see how my nightly build 
goes out which does compilation on alot of

mips, arm, powerpc etc. platforms



Of course, I have my own "I will delay 4.18 by a week" to blame for the timing.

So if you can find the places that break, and add the right header,
and send me a patch for all the ones you find, that would be lovely.

will do so. but for now it seems that this was really the only one


It's not necessarilky always  or  that makes
sense to add as an include. As mentioned, sometimes it's
 or similar.


mmh why? i prefer to include the correct header which references the 
function or macro instead of adding
a header which finds the right way by multiple iterations. its more 
transparent



Sebastian

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 21:42 schrieb Linus Torvalds:

On Wed, Aug 15, 2018 at 12:26 PM Guenter Roeck  wrote:

Also seen in mainline. Meaning my non-SMP test builds are broken. Hmm.

Grr. I think it's due mainly due to commit 447ae3166702 ("x86: Don't
include linux/irq.h from asm/hardirq.h"), which exposes a number of
files that had some dodgy include file dependenencies, and just
randomly happened to get it right because of that odd include that
caused problems.

correct.


That commit itself is definitely the right thing to do, but yes, we
clearly had a lot of cases of things getting core header files
included purely by luck.

And because this was all done under embargo, we didn't get the kind of
test robot coverage we usually get.

Part of it can also be due to subtle merge issues - even if the
original branch got good coverage, later changes sometimes ended up
adding things like that.

For example, my merge of the L1TF code found that in the meantime,
arch/x86/kernel/kvmclock.c had added a call to kzalloc(), which used
to work just fine, but with the header cleanup it turned out that
kvmclock.c had never included , so now it didn't build
right.

And that was just the one I noticed because of my limited build tests.

And yes, every single developer has CONFIG_SMP in their config, but
perhaps equally importantly, I suspect CONFIG_SMP ends up getting more
header files included almost by mistake, so it can _continue_ to hide
these kinds of incomplete header file includes that just happen to
work.


Anyway, care to send a proper patch ? I am sure Linus will be more
than happy to apply it.

I think "happy" is too strong a word for my state of mind with all
this, but yes, I'll apply it, and you'll get the glory of fixing some
configuration that clearly didn't get properly tested.

In the meantime, maybe I should just do a "make allmodconfig" and then
disable SMP and see if that shows anything for me.


if it would be helpfull i can do this quick here using the latest 
vanilla tree


Sebastian



   Linus

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 21:42 schrieb Linus Torvalds:

On Wed, Aug 15, 2018 at 12:26 PM Guenter Roeck  wrote:

Also seen in mainline. Meaning my non-SMP test builds are broken. Hmm.

Grr. I think it's due mainly due to commit 447ae3166702 ("x86: Don't
include linux/irq.h from asm/hardirq.h"), which exposes a number of
files that had some dodgy include file dependenencies, and just
randomly happened to get it right because of that odd include that
caused problems.

correct.


That commit itself is definitely the right thing to do, but yes, we
clearly had a lot of cases of things getting core header files
included purely by luck.

And because this was all done under embargo, we didn't get the kind of
test robot coverage we usually get.

Part of it can also be due to subtle merge issues - even if the
original branch got good coverage, later changes sometimes ended up
adding things like that.

For example, my merge of the L1TF code found that in the meantime,
arch/x86/kernel/kvmclock.c had added a call to kzalloc(), which used
to work just fine, but with the header cleanup it turned out that
kvmclock.c had never included , so now it didn't build
right.

And that was just the one I noticed because of my limited build tests.

And yes, every single developer has CONFIG_SMP in their config, but
perhaps equally importantly, I suspect CONFIG_SMP ends up getting more
header files included almost by mistake, so it can _continue_ to hide
these kinds of incomplete header file includes that just happen to
work.


Anyway, care to send a proper patch ? I am sure Linus will be more
than happy to apply it.

I think "happy" is too strong a word for my state of mind with all
this, but yes, I'll apply it, and you'll get the glory of fixing some
configuration that clearly didn't get properly tested.

In the meantime, maybe I should just do a "make allmodconfig" and then
disable SMP and see if that shows anything for me.


if it would be helpfull i can do this quick here using the latest 
vanilla tree


Sebastian



   Linus

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 20:55 schrieb Guenter Roeck:

On Wed, Aug 15, 2018 at 08:27:00PM +0200, Sebastian Gottschall wrote:

if i fix the other error (can be reproduced with disable smp on standard
i386 build)

another raises up again related to smp. to be serious. this patchset of x86
patches is absolutelly broken and put together without any care. not a
simple compile test has been done

sorry for beeing a little bit upset. i'm sure i will find other bugs if i go
deeper


It might possibly help if you would consider to publish your configuration(s).

As for "not a simple compile test has been done", please have a look
at http://kerneltests.org/builders. I guess those compile (and boot)
tests don't count as "simple". I assume the same applies to all the
builds done by 0day and all the other test builders.

Guenter


it was nothing special. just a standard x86 build with smp disabled. 
that triggers all of them. so this should be a common build 
configuration for testing

these issues are covered by the rc3 patch of 4.9 right now

the issue reported by sven can be triggered by just compiling rtc-cmos.c 
which is caused by the change in dmi.h  (asm/io.h was replaced by 
linux/io.h)
so this driver should be included in all x86 and x64 builds and must be 
uncovered in any simple compile test


btw. this issue is still unresolved but simple to fix

--- arch/x86/include/asm/i8259.h    (revision 36620)
+++ arch/x86/include/asm/i8259.h    (working copy)
@@ -2,6 +2,7 @@
 #define _ASM_X86_I8259_H

 #include 
+#include 

 extern unsigned int cached_irq_mask;


Sebastian

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 20:55 schrieb Guenter Roeck:

On Wed, Aug 15, 2018 at 08:27:00PM +0200, Sebastian Gottschall wrote:

if i fix the other error (can be reproduced with disable smp on standard
i386 build)

another raises up again related to smp. to be serious. this patchset of x86
patches is absolutelly broken and put together without any care. not a
simple compile test has been done

sorry for beeing a little bit upset. i'm sure i will find other bugs if i go
deeper


It might possibly help if you would consider to publish your configuration(s).

As for "not a simple compile test has been done", please have a look
at http://kerneltests.org/builders. I guess those compile (and boot)
tests don't count as "simple". I assume the same applies to all the
builds done by 0day and all the other test builders.

Guenter


it was nothing special. just a standard x86 build with smp disabled. 
that triggers all of them. so this should be a common build 
configuration for testing

these issues are covered by the rc3 patch of 4.9 right now

the issue reported by sven can be triggered by just compiling rtc-cmos.c 
which is caused by the change in dmi.h  (asm/io.h was replaced by 
linux/io.h)
so this driver should be included in all x86 and x64 builds and must be 
uncovered in any simple compile test


btw. this issue is still unresolved but simple to fix

--- arch/x86/include/asm/i8259.h    (revision 36620)
+++ arch/x86/include/asm/i8259.h    (working copy)
@@ -2,6 +2,7 @@
 #define _ASM_X86_I8259_H

 #include 
+#include 

 extern unsigned int cached_irq_mask;


Sebastian

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 20:26 schrieb Linus Torvalds:

On Wed, Aug 15, 2018 at 11:22 AM Sebastian Gottschall
 wrote:

btw. i found another compile error with x86 :-)

This should already be fixed by commit d0055f351e64 ("x86/smp: fix
non-SMP broken build due to redefinition of
apic_id_is_primary_thread").

   Linus


Hello Linus

unfortunatly there are numerous other non smp compile issues. this patch 
covers just one out of 3 found so far



Sebastian

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 20:26 schrieb Linus Torvalds:

On Wed, Aug 15, 2018 at 11:22 AM Sebastian Gottschall
 wrote:

btw. i found another compile error with x86 :-)

This should already be fixed by commit d0055f351e64 ("x86/smp: fix
non-SMP broken build due to redefinition of
apic_id_is_primary_thread").

   Linus


Hello Linus

unfortunatly there are numerous other non smp compile issues. this patch 
covers just one out of 3 found so far



Sebastian

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

if i fix the other error (can be reproduced with disable smp on standard 
i386 build)


another raises up again related to smp. to be serious. this patchset of 
x86 patches is absolutelly broken and put together without any care. not 
a simple compile test has been done


sorry for beeing a little bit upset. i'm sure i will find other bugs if 
i go deeper



arch/x86/kernel/cpu/amd.c: In function 'early_init_amd':
arch/x86/kernel/cpu/amd.c:660:2: error: implicit declaration of function 
'amd_get_topology_early'; did you mean 'cpu_smt_check_topology_early'? 
[-Werror=implicit-function-declaration]

  amd_get_topology_early(c);
  ^~
  cpu_smt_check_topology_early

Am 15.08.2018 um 19:52 schrieb Sven Joachim:

On 2018-08-15 19:01 +0200, Sebastian Gottschall wrote:


nother issue seen on xscale and as it affects all non SMP configured kernels


kernel/cpu.c: In function 'boot_cpu_hotplug_init':
kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member
named 'booted_once'
   this_cpu_write(cpuhp_state.booted_once, true);

I got a different error in 4.9.120 with CONFIG_SMP unset:

,
| CC  drivers/rtc/rtc-cmos.o
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h: In function 'inb_pic':
| ./arch/x86/include/asm/i8259.h:32:24: error: implicit declaration of function 
'inb' [-Werror=implicit-function-declaration]
|   unsigned char value = inb(port);
| ^~~
| ./arch/x86/include/asm/i8259.h: In function 'outb_pic':
| ./arch/x86/include/asm/i8259.h:45:2: error: implicit declaration of function 
'outb' [-Werror=implicit-function-declaration]
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h: At top level:
| ./arch/x86/include/asm/io.h:277:20: warning: conflicting types for 'outb'
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| ./arch/x86/include/asm/io.h:277:20: error: static declaration of 'outb' 
follows non-static declaration
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:45:2: note: previous implicit declaration of 
'outb' was here
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h:283:29: error: conflicting types for 'inb'
|  static inline unsigned type in##bwl(int port)\
|  ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:32:24: note: previous implicit declaration of 
'inb' was here
|   unsigned char value = inb(port);
`

Cheers,
Sven

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

if i fix the other error (can be reproduced with disable smp on standard 
i386 build)


another raises up again related to smp. to be serious. this patchset of 
x86 patches is absolutelly broken and put together without any care. not 
a simple compile test has been done


sorry for beeing a little bit upset. i'm sure i will find other bugs if 
i go deeper



arch/x86/kernel/cpu/amd.c: In function 'early_init_amd':
arch/x86/kernel/cpu/amd.c:660:2: error: implicit declaration of function 
'amd_get_topology_early'; did you mean 'cpu_smt_check_topology_early'? 
[-Werror=implicit-function-declaration]

  amd_get_topology_early(c);
  ^~
  cpu_smt_check_topology_early

Am 15.08.2018 um 19:52 schrieb Sven Joachim:

On 2018-08-15 19:01 +0200, Sebastian Gottschall wrote:


nother issue seen on xscale and as it affects all non SMP configured kernels


kernel/cpu.c: In function 'boot_cpu_hotplug_init':
kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member
named 'booted_once'
   this_cpu_write(cpuhp_state.booted_once, true);

I got a different error in 4.9.120 with CONFIG_SMP unset:

,
| CC  drivers/rtc/rtc-cmos.o
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h: In function 'inb_pic':
| ./arch/x86/include/asm/i8259.h:32:24: error: implicit declaration of function 
'inb' [-Werror=implicit-function-declaration]
|   unsigned char value = inb(port);
| ^~~
| ./arch/x86/include/asm/i8259.h: In function 'outb_pic':
| ./arch/x86/include/asm/i8259.h:45:2: error: implicit declaration of function 
'outb' [-Werror=implicit-function-declaration]
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h: At top level:
| ./arch/x86/include/asm/io.h:277:20: warning: conflicting types for 'outb'
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| ./arch/x86/include/asm/io.h:277:20: error: static declaration of 'outb' 
follows non-static declaration
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:45:2: note: previous implicit declaration of 
'outb' was here
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h:283:29: error: conflicting types for 'inb'
|  static inline unsigned type in##bwl(int port)\
|  ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:32:24: note: previous implicit declaration of 
'inb' was here
|   unsigned char value = inb(port);
`

Cheers,
Sven

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 19:52 schrieb Sven Joachim:

On 2018-08-15 19:01 +0200, Sebastian Gottschall wrote:


nother issue seen on xscale and as it affects all non SMP configured kernels


kernel/cpu.c: In function 'boot_cpu_hotplug_init':
kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member
named 'booted_once'
   this_cpu_write(cpuhp_state.booted_once, true);

I got a different error in 4.9.120 with CONFIG_SMP unset:


that doesnt make it better :-) i havend checked x86 without smp, just 
xscale. your error doesnt affect xscale which is a arm platform. all 
these issues seem to affect 4.14 as well


btw. i found another compile error with x86 :-)


arch/x86/kernel/apic/apic.c:2050:6: error: redefinition of 
'apic_id_is_primary_thread'

 bool apic_id_is_primary_thread(unsigned int apicid)
  ^
In file included from ./arch/x86/include/asm/smp.h:12,
 from ./arch/x86/include/asm/tlbflush.h:10,
 from ./arch/x86/include/asm/highmem.h:26,
 from ./include/linux/highmem.h:34,
 from ./include/linux/pagemap.h:10,
 from ./arch/x86/include/asm/pgalloc.h:6,
 from arch/x86/kernel/apic/apic.c:43:
./arch/x86/include/asm/apic.h:641:20: note: previous definition of 
'apic_id_is_primary_thread' was here
 static inline bool apic_id_is_primary_thread(unsigned int id) { return 
false; }




Sebastian



,
| CC  drivers/rtc/rtc-cmos.o
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h: In function 'inb_pic':
| ./arch/x86/include/asm/i8259.h:32:24: error: implicit declaration of function 
'inb' [-Werror=implicit-function-declaration]
|   unsigned char value = inb(port);
| ^~~
| ./arch/x86/include/asm/i8259.h: In function 'outb_pic':
| ./arch/x86/include/asm/i8259.h:45:2: error: implicit declaration of function 
'outb' [-Werror=implicit-function-declaration]
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h: At top level:
| ./arch/x86/include/asm/io.h:277:20: warning: conflicting types for 'outb'
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| ./arch/x86/include/asm/io.h:277:20: error: static declaration of 'outb' 
follows non-static declaration
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:45:2: note: previous implicit declaration of 
'outb' was here
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h:283:29: error: conflicting types for 'inb'
|  static inline unsigned type in##bwl(int port)\
|  ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:32:24: note: previous implicit declaration of 
'inb' was here
|   unsigned char value = inb(port);
`

Cheers,
Sven

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

Am 15.08.2018 um 19:52 schrieb Sven Joachim:

On 2018-08-15 19:01 +0200, Sebastian Gottschall wrote:


nother issue seen on xscale and as it affects all non SMP configured kernels


kernel/cpu.c: In function 'boot_cpu_hotplug_init':
kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member
named 'booted_once'
   this_cpu_write(cpuhp_state.booted_once, true);

I got a different error in 4.9.120 with CONFIG_SMP unset:


that doesnt make it better :-) i havend checked x86 without smp, just 
xscale. your error doesnt affect xscale which is a arm platform. all 
these issues seem to affect 4.14 as well


btw. i found another compile error with x86 :-)


arch/x86/kernel/apic/apic.c:2050:6: error: redefinition of 
'apic_id_is_primary_thread'

 bool apic_id_is_primary_thread(unsigned int apicid)
  ^
In file included from ./arch/x86/include/asm/smp.h:12,
 from ./arch/x86/include/asm/tlbflush.h:10,
 from ./arch/x86/include/asm/highmem.h:26,
 from ./include/linux/highmem.h:34,
 from ./include/linux/pagemap.h:10,
 from ./arch/x86/include/asm/pgalloc.h:6,
 from arch/x86/kernel/apic/apic.c:43:
./arch/x86/include/asm/apic.h:641:20: note: previous definition of 
'apic_id_is_primary_thread' was here
 static inline bool apic_id_is_primary_thread(unsigned int id) { return 
false; }




Sebastian



,
| CC  drivers/rtc/rtc-cmos.o
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h: In function 'inb_pic':
| ./arch/x86/include/asm/i8259.h:32:24: error: implicit declaration of function 
'inb' [-Werror=implicit-function-declaration]
|   unsigned char value = inb(port);
| ^~~
| ./arch/x86/include/asm/i8259.h: In function 'outb_pic':
| ./arch/x86/include/asm/i8259.h:45:2: error: implicit declaration of function 
'outb' [-Werror=implicit-function-declaration]
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h: At top level:
| ./arch/x86/include/asm/io.h:277:20: warning: conflicting types for 'outb'
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| ./arch/x86/include/asm/io.h:277:20: error: static declaration of 'outb' 
follows non-static declaration
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:45:2: note: previous implicit declaration of 
'outb' was here
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h:283:29: error: conflicting types for 'inb'
|  static inline unsigned type in##bwl(int port)\
|  ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:32:24: note: previous implicit declaration of 
'inb' was here
|   unsigned char value = inb(port);
`

Cheers,
Sven

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

nother issue seen on xscale and as it affects all non SMP configured kernels


kernel/cpu.c: In function 'boot_cpu_hotplug_init':
kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member 
named 'booted_once'

  this_cpu_write(cpuhp_state.booted_once, true);

Am 14.08.2018 um 19:16 schrieb Greg Kroah-Hartman:

This is the start of the stable review cycle for the 4.9.120 release.
There are 107 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Aug 16 17:14:53 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.120-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
 Linux 4.9.120-rc1

Josh Poimboeuf 
 x86/microcode: Allow late microcode loading with SMT disabled

Ashok Raj 
 x86/microcode: Do not upload microcode if CPUs are offline

David Woodhouse 
 tools headers: Synchronise x86 cpufeatures.h for L1TF additions

Andi Kleen 
 x86/mm/kmmio: Make the tracer robust against L1TF

Andi Kleen 
 x86/mm/pat: Make set_memory_np() L1TF safe

Andi Kleen 
 x86/speculation/l1tf: Make pmd/pud_mknotpresent() invert

Andi Kleen 
 x86/speculation/l1tf: Invert all not present mappings

Thomas Gleixner 
 cpu/hotplug: Fix SMT supported evaluation

Paolo Bonzini 
 KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry

Paolo Bonzini 
 x86/speculation: Use ARCH_CAPABILITIES to skip L1D flush on vmentry

Paolo Bonzini 
 x86/speculation: Simplify sysfs report of VMX L1TF vulnerability

Paolo Bonzini 
 KVM: VMX: support MSR_IA32_ARCH_CAPABILITIES as a feature MSR

Wanpeng Li 
 KVM: X86: Allow userspace to define the microcode version

Wanpeng Li 
 KVM: X86: Introduce kvm_get_msr_feature()

Tom Lendacky 
 KVM: SVM: Add MSR-based feature support for serializing LFENCE

Tom Lendacky 
 KVM: x86: Add a framework for supporting MSR-based features

Thomas Gleixner 
 Documentation/l1tf: Remove Yonah processors from not vulnerable list

Nicolai Stange 
 x86/KVM/VMX: Don't set l1tf_flush_l1d from vmx_handle_external_intr()

Nicolai Stange 
 x86/irq: Let interrupt handlers set kvm_cpu_l1tf_flush_l1d

Nicolai Stange 
 x86: Don't include linux/irq.h from asm/hardirq.h

Nicolai Stange 
 x86/KVM/VMX: Introduce per-host-cpu analogue of l1tf_flush_l1d

Nicolai Stange 
 x86/irq: Demote irq_cpustat_t::__softirq_pending to u16

Nicolai Stange 
 x86/KVM/VMX: Move the l1tf_flush_l1d test to vmx_l1d_flush()

Nicolai Stange 
 x86/KVM/VMX: Replace 'vmx_l1d_flush_always' with 'vmx_l1d_flush_cond'

Nicolai Stange 
 x86/KVM/VMX: Don't set l1tf_flush_l1d to true from vmx_l1d_flush()

Josh Poimboeuf 
 cpu/hotplug: detect SMT disabled by BIOS

Tony Luck 
 Documentation/l1tf: Fix typos

Nicolai Stange 
 x86/KVM/VMX: Initialize the vmx_l1d_flush_pages' content

Thomas Gleixner 
 Documentation: Add section about CPU vulnerabilities

Jiri Kosina 
 x86/bugs, kvm: Introduce boot-time control of L1TF mitigations

Thomas Gleixner 
 cpu/hotplug: Set CPU_SMT_NOT_SUPPORTED early

Jiri Kosina 
 cpu/hotplug: Expose SMT control init function

Thomas Gleixner 
 x86/kvm: Allow runtime control of L1D flush

Thomas Gleixner 
 x86/kvm: Serialize L1D flush parameter setter

Thomas Gleixner 
 x86/kvm: Add static key for flush always

Thomas Gleixner 
 x86/kvm: Move l1tf setup function

Thomas Gleixner 
 x86/l1tf: Handle EPT disabled state proper

Thomas Gleixner 
 x86/kvm: Drop L1TF MSR list approach

Thomas Gleixner 
 x86/litf: Introduce vmx status variable

Thomas Gleixner 
 cpu/hotplug: Online siblings when SMT control is turned on

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Use MSR save list for IA32_FLUSH_CMD if required

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Extend add_atomic_switch_msr() to allow VMENTER only MSRs

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Separate the VMX AUTOLOAD guest/host number accounting

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Add find_msr() helper function

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Split the VMX MSR LOAD structures to have an host/guest 
numbers

Jim Mattson 
 kvm: nVMX: Update MSR load counts on a VMCS switch

Paolo Bonzini 
 x86/KVM/VMX: Add L1D flush logic

Paolo Bonzini 
 x86/KVM/VMX: Add L1D MSR based flush

Paolo Bonzini 
 x86/KVM/VMX: Add L1D flush algorithm

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Add module argument for L1TF mitigation

Konrad Rzeszutek Wilk 
 x86/KVM: Warn user if KVM is loaded SMT and L1TF CPU bug being present

Thomas Gleixner 
 

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

nother issue seen on xscale and as it affects all non SMP configured kernels


kernel/cpu.c: In function 'boot_cpu_hotplug_init':
kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member 
named 'booted_once'

  this_cpu_write(cpuhp_state.booted_once, true);

Am 14.08.2018 um 19:16 schrieb Greg Kroah-Hartman:

This is the start of the stable review cycle for the 4.9.120 release.
There are 107 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Aug 16 17:14:53 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.120-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
 Linux 4.9.120-rc1

Josh Poimboeuf 
 x86/microcode: Allow late microcode loading with SMT disabled

Ashok Raj 
 x86/microcode: Do not upload microcode if CPUs are offline

David Woodhouse 
 tools headers: Synchronise x86 cpufeatures.h for L1TF additions

Andi Kleen 
 x86/mm/kmmio: Make the tracer robust against L1TF

Andi Kleen 
 x86/mm/pat: Make set_memory_np() L1TF safe

Andi Kleen 
 x86/speculation/l1tf: Make pmd/pud_mknotpresent() invert

Andi Kleen 
 x86/speculation/l1tf: Invert all not present mappings

Thomas Gleixner 
 cpu/hotplug: Fix SMT supported evaluation

Paolo Bonzini 
 KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry

Paolo Bonzini 
 x86/speculation: Use ARCH_CAPABILITIES to skip L1D flush on vmentry

Paolo Bonzini 
 x86/speculation: Simplify sysfs report of VMX L1TF vulnerability

Paolo Bonzini 
 KVM: VMX: support MSR_IA32_ARCH_CAPABILITIES as a feature MSR

Wanpeng Li 
 KVM: X86: Allow userspace to define the microcode version

Wanpeng Li 
 KVM: X86: Introduce kvm_get_msr_feature()

Tom Lendacky 
 KVM: SVM: Add MSR-based feature support for serializing LFENCE

Tom Lendacky 
 KVM: x86: Add a framework for supporting MSR-based features

Thomas Gleixner 
 Documentation/l1tf: Remove Yonah processors from not vulnerable list

Nicolai Stange 
 x86/KVM/VMX: Don't set l1tf_flush_l1d from vmx_handle_external_intr()

Nicolai Stange 
 x86/irq: Let interrupt handlers set kvm_cpu_l1tf_flush_l1d

Nicolai Stange 
 x86: Don't include linux/irq.h from asm/hardirq.h

Nicolai Stange 
 x86/KVM/VMX: Introduce per-host-cpu analogue of l1tf_flush_l1d

Nicolai Stange 
 x86/irq: Demote irq_cpustat_t::__softirq_pending to u16

Nicolai Stange 
 x86/KVM/VMX: Move the l1tf_flush_l1d test to vmx_l1d_flush()

Nicolai Stange 
 x86/KVM/VMX: Replace 'vmx_l1d_flush_always' with 'vmx_l1d_flush_cond'

Nicolai Stange 
 x86/KVM/VMX: Don't set l1tf_flush_l1d to true from vmx_l1d_flush()

Josh Poimboeuf 
 cpu/hotplug: detect SMT disabled by BIOS

Tony Luck 
 Documentation/l1tf: Fix typos

Nicolai Stange 
 x86/KVM/VMX: Initialize the vmx_l1d_flush_pages' content

Thomas Gleixner 
 Documentation: Add section about CPU vulnerabilities

Jiri Kosina 
 x86/bugs, kvm: Introduce boot-time control of L1TF mitigations

Thomas Gleixner 
 cpu/hotplug: Set CPU_SMT_NOT_SUPPORTED early

Jiri Kosina 
 cpu/hotplug: Expose SMT control init function

Thomas Gleixner 
 x86/kvm: Allow runtime control of L1D flush

Thomas Gleixner 
 x86/kvm: Serialize L1D flush parameter setter

Thomas Gleixner 
 x86/kvm: Add static key for flush always

Thomas Gleixner 
 x86/kvm: Move l1tf setup function

Thomas Gleixner 
 x86/l1tf: Handle EPT disabled state proper

Thomas Gleixner 
 x86/kvm: Drop L1TF MSR list approach

Thomas Gleixner 
 x86/litf: Introduce vmx status variable

Thomas Gleixner 
 cpu/hotplug: Online siblings when SMT control is turned on

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Use MSR save list for IA32_FLUSH_CMD if required

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Extend add_atomic_switch_msr() to allow VMENTER only MSRs

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Separate the VMX AUTOLOAD guest/host number accounting

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Add find_msr() helper function

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Split the VMX MSR LOAD structures to have an host/guest 
numbers

Jim Mattson 
 kvm: nVMX: Update MSR load counts on a VMCS switch

Paolo Bonzini 
 x86/KVM/VMX: Add L1D flush logic

Paolo Bonzini 
 x86/KVM/VMX: Add L1D MSR based flush

Paolo Bonzini 
 x86/KVM/VMX: Add L1D flush algorithm

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Add module argument for L1TF mitigation

Konrad Rzeszutek Wilk 
 x86/KVM: Warn user if KVM is loaded SMT and L1TF CPU bug being present

Thomas Gleixner 
 

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

if SWAP is disabled in kernel config, the following compile error will 
raise up with this release


arch/x86/built-in.o: in function `max_swapfile_size': (.text+0x3bba1): 
undefined reference to `generic_max_swapfile_size'


of course this is simple to fix. the function max_swapfile_size must be 
excluded if CONFIG_SWAP is disabled


Sebastian

Am 14.08.2018 um 19:16 schrieb Greg Kroah-Hartman:

This is the start of the stable review cycle for the 4.9.120 release.
There are 107 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Aug 16 17:14:53 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.120-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
 Linux 4.9.120-rc1

Josh Poimboeuf 
 x86/microcode: Allow late microcode loading with SMT disabled

Ashok Raj 
 x86/microcode: Do not upload microcode if CPUs are offline

David Woodhouse 
 tools headers: Synchronise x86 cpufeatures.h for L1TF additions

Andi Kleen 
 x86/mm/kmmio: Make the tracer robust against L1TF

Andi Kleen 
 x86/mm/pat: Make set_memory_np() L1TF safe

Andi Kleen 
 x86/speculation/l1tf: Make pmd/pud_mknotpresent() invert

Andi Kleen 
 x86/speculation/l1tf: Invert all not present mappings

Thomas Gleixner 
 cpu/hotplug: Fix SMT supported evaluation

Paolo Bonzini 
 KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry

Paolo Bonzini 
 x86/speculation: Use ARCH_CAPABILITIES to skip L1D flush on vmentry

Paolo Bonzini 
 x86/speculation: Simplify sysfs report of VMX L1TF vulnerability

Paolo Bonzini 
 KVM: VMX: support MSR_IA32_ARCH_CAPABILITIES as a feature MSR

Wanpeng Li 
 KVM: X86: Allow userspace to define the microcode version

Wanpeng Li 
 KVM: X86: Introduce kvm_get_msr_feature()

Tom Lendacky 
 KVM: SVM: Add MSR-based feature support for serializing LFENCE

Tom Lendacky 
 KVM: x86: Add a framework for supporting MSR-based features

Thomas Gleixner 
 Documentation/l1tf: Remove Yonah processors from not vulnerable list

Nicolai Stange 
 x86/KVM/VMX: Don't set l1tf_flush_l1d from vmx_handle_external_intr()

Nicolai Stange 
 x86/irq: Let interrupt handlers set kvm_cpu_l1tf_flush_l1d

Nicolai Stange 
 x86: Don't include linux/irq.h from asm/hardirq.h

Nicolai Stange 
 x86/KVM/VMX: Introduce per-host-cpu analogue of l1tf_flush_l1d

Nicolai Stange 
 x86/irq: Demote irq_cpustat_t::__softirq_pending to u16

Nicolai Stange 
 x86/KVM/VMX: Move the l1tf_flush_l1d test to vmx_l1d_flush()

Nicolai Stange 
 x86/KVM/VMX: Replace 'vmx_l1d_flush_always' with 'vmx_l1d_flush_cond'

Nicolai Stange 
 x86/KVM/VMX: Don't set l1tf_flush_l1d to true from vmx_l1d_flush()

Josh Poimboeuf 
 cpu/hotplug: detect SMT disabled by BIOS

Tony Luck 
 Documentation/l1tf: Fix typos

Nicolai Stange 
 x86/KVM/VMX: Initialize the vmx_l1d_flush_pages' content

Thomas Gleixner 
 Documentation: Add section about CPU vulnerabilities

Jiri Kosina 
 x86/bugs, kvm: Introduce boot-time control of L1TF mitigations

Thomas Gleixner 
 cpu/hotplug: Set CPU_SMT_NOT_SUPPORTED early

Jiri Kosina 
 cpu/hotplug: Expose SMT control init function

Thomas Gleixner 
 x86/kvm: Allow runtime control of L1D flush

Thomas Gleixner 
 x86/kvm: Serialize L1D flush parameter setter

Thomas Gleixner 
 x86/kvm: Add static key for flush always

Thomas Gleixner 
 x86/kvm: Move l1tf setup function

Thomas Gleixner 
 x86/l1tf: Handle EPT disabled state proper

Thomas Gleixner 
 x86/kvm: Drop L1TF MSR list approach

Thomas Gleixner 
 x86/litf: Introduce vmx status variable

Thomas Gleixner 
 cpu/hotplug: Online siblings when SMT control is turned on

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Use MSR save list for IA32_FLUSH_CMD if required

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Extend add_atomic_switch_msr() to allow VMENTER only MSRs

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Separate the VMX AUTOLOAD guest/host number accounting

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Add find_msr() helper function

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Split the VMX MSR LOAD structures to have an host/guest 
numbers

Jim Mattson 
 kvm: nVMX: Update MSR load counts on a VMCS switch

Paolo Bonzini 
 x86/KVM/VMX: Add L1D flush logic

Paolo Bonzini 
 x86/KVM/VMX: Add L1D MSR based flush

Paolo Bonzini 
 x86/KVM/VMX: Add L1D flush algorithm

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Add module argument for L1TF mitigation

Konrad Rzeszutek Wilk 
 x86/KVM: Warn user if 

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sebastian Gottschall]

if SWAP is disabled in kernel config, the following compile error will 
raise up with this release


arch/x86/built-in.o: in function `max_swapfile_size': (.text+0x3bba1): 
undefined reference to `generic_max_swapfile_size'


of course this is simple to fix. the function max_swapfile_size must be 
excluded if CONFIG_SWAP is disabled


Sebastian

Am 14.08.2018 um 19:16 schrieb Greg Kroah-Hartman:

This is the start of the stable review cycle for the 4.9.120 release.
There are 107 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Aug 16 17:14:53 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.120-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
 Linux 4.9.120-rc1

Josh Poimboeuf 
 x86/microcode: Allow late microcode loading with SMT disabled

Ashok Raj 
 x86/microcode: Do not upload microcode if CPUs are offline

David Woodhouse 
 tools headers: Synchronise x86 cpufeatures.h for L1TF additions

Andi Kleen 
 x86/mm/kmmio: Make the tracer robust against L1TF

Andi Kleen 
 x86/mm/pat: Make set_memory_np() L1TF safe

Andi Kleen 
 x86/speculation/l1tf: Make pmd/pud_mknotpresent() invert

Andi Kleen 
 x86/speculation/l1tf: Invert all not present mappings

Thomas Gleixner 
 cpu/hotplug: Fix SMT supported evaluation

Paolo Bonzini 
 KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry

Paolo Bonzini 
 x86/speculation: Use ARCH_CAPABILITIES to skip L1D flush on vmentry

Paolo Bonzini 
 x86/speculation: Simplify sysfs report of VMX L1TF vulnerability

Paolo Bonzini 
 KVM: VMX: support MSR_IA32_ARCH_CAPABILITIES as a feature MSR

Wanpeng Li 
 KVM: X86: Allow userspace to define the microcode version

Wanpeng Li 
 KVM: X86: Introduce kvm_get_msr_feature()

Tom Lendacky 
 KVM: SVM: Add MSR-based feature support for serializing LFENCE

Tom Lendacky 
 KVM: x86: Add a framework for supporting MSR-based features

Thomas Gleixner 
 Documentation/l1tf: Remove Yonah processors from not vulnerable list

Nicolai Stange 
 x86/KVM/VMX: Don't set l1tf_flush_l1d from vmx_handle_external_intr()

Nicolai Stange 
 x86/irq: Let interrupt handlers set kvm_cpu_l1tf_flush_l1d

Nicolai Stange 
 x86: Don't include linux/irq.h from asm/hardirq.h

Nicolai Stange 
 x86/KVM/VMX: Introduce per-host-cpu analogue of l1tf_flush_l1d

Nicolai Stange 
 x86/irq: Demote irq_cpustat_t::__softirq_pending to u16

Nicolai Stange 
 x86/KVM/VMX: Move the l1tf_flush_l1d test to vmx_l1d_flush()

Nicolai Stange 
 x86/KVM/VMX: Replace 'vmx_l1d_flush_always' with 'vmx_l1d_flush_cond'

Nicolai Stange 
 x86/KVM/VMX: Don't set l1tf_flush_l1d to true from vmx_l1d_flush()

Josh Poimboeuf 
 cpu/hotplug: detect SMT disabled by BIOS

Tony Luck 
 Documentation/l1tf: Fix typos

Nicolai Stange 
 x86/KVM/VMX: Initialize the vmx_l1d_flush_pages' content

Thomas Gleixner 
 Documentation: Add section about CPU vulnerabilities

Jiri Kosina 
 x86/bugs, kvm: Introduce boot-time control of L1TF mitigations

Thomas Gleixner 
 cpu/hotplug: Set CPU_SMT_NOT_SUPPORTED early

Jiri Kosina 
 cpu/hotplug: Expose SMT control init function

Thomas Gleixner 
 x86/kvm: Allow runtime control of L1D flush

Thomas Gleixner 
 x86/kvm: Serialize L1D flush parameter setter

Thomas Gleixner 
 x86/kvm: Add static key for flush always

Thomas Gleixner 
 x86/kvm: Move l1tf setup function

Thomas Gleixner 
 x86/l1tf: Handle EPT disabled state proper

Thomas Gleixner 
 x86/kvm: Drop L1TF MSR list approach

Thomas Gleixner 
 x86/litf: Introduce vmx status variable

Thomas Gleixner 
 cpu/hotplug: Online siblings when SMT control is turned on

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Use MSR save list for IA32_FLUSH_CMD if required

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Extend add_atomic_switch_msr() to allow VMENTER only MSRs

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Separate the VMX AUTOLOAD guest/host number accounting

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Add find_msr() helper function

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Split the VMX MSR LOAD structures to have an host/guest 
numbers

Jim Mattson 
 kvm: nVMX: Update MSR load counts on a VMCS switch

Paolo Bonzini 
 x86/KVM/VMX: Add L1D flush logic

Paolo Bonzini 
 x86/KVM/VMX: Add L1D MSR based flush

Paolo Bonzini 
 x86/KVM/VMX: Add L1D flush algorithm

Konrad Rzeszutek Wilk 
 x86/KVM/VMX: Add module argument for L1TF mitigation

Konrad Rzeszutek Wilk 
 x86/KVM: Warn user if 

Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering

[Sebastian Gottschall]

Am 31.05.2018 um 18:57 schrieb Bjorn Andersson:

On Thu 31 May 04:45 PDT 2018, Greg Kroah-Hartman wrote:


On Thu, May 31, 2018 at 01:21:56PM +0200, Sebastian Gottschall wrote:

Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Andersson 

[ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]

The base of the TLMM gpiochip should not be statically defined as 0, fix
this to not artificially restrict the existence of multiple pinctrl-msm
devices.

Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Reported-by: Timur Tabi 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
   drivers/pinctrl/qcom/pinctrl-msm.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pinc
return -EINVAL;
chip = >chip;
-   chip->base = 0;
+   chip->base = -1;
chip->ngpio = ngpio;
chip->label = dev_name(pctrl->dev);
chip->parent = pctrl->dev;

this patch creates a regression for me. on ipq8064 the systems gpios now
start somewhere in the sky

new layout

lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip373 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip408 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip408
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip443 ->
../../devices/platform/soc/80.pinmux/gpio/gpiochip443


before the patch

lrwxrwxrwx    1 root root 0 Jan  1  1970 gpiochip0 ->
../../devices/platform/soc/80.pinmux/gpio/gpiochip0
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip442 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip477 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip477


this broke my userspace gpio handling. i can override this, but still it
doesnt look correct since there is a hole at the beginng likelly reserved by
unused arm gpios

So does this mean that 4.17-rc is also broken for you?  If so, this
needs to be reverted there as well.

Bjorn, any ideas?


The Qualcomm TLMM (pinctrl) driver was introduced long after it was
decided that the kernel should not rely on global/static gpio numbering.

But due to a mistake on my part the dynamic gpio base for this gpiochip
was always 0, which the offending patch corrects.


So writing user space code relying on the gpio numbering for this chip
has always been incorrect, just as it is for the other two gpiochips
listed above.


The original objection for backporting this patch was a touchscreen
driver stopped working on 4.4, but the driver clearly doesn't depend on
global or static numbering of gpios. I don't think this was ever root
caused.


I guess the pragmatic approach would be to come up with something like
Timur's suggested fix that makes the first instance of this driver use
base = 0 and then use dynamic numbering for the rest, to maintain
support for this incorrect usage of the gpio sysfs interface. (Although
that would probably break if Timur's customers move their user space to
the new platform as "the first instance" isn't deterministic).

Regards,
Bjorn

that would at least guarantee backward compatiblity. i'm fine with that

Sebastian

Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering

[Sebastian Gottschall]

Am 31.05.2018 um 18:57 schrieb Bjorn Andersson:

On Thu 31 May 04:45 PDT 2018, Greg Kroah-Hartman wrote:


On Thu, May 31, 2018 at 01:21:56PM +0200, Sebastian Gottschall wrote:

Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Andersson 

[ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]

The base of the TLMM gpiochip should not be statically defined as 0, fix
this to not artificially restrict the existence of multiple pinctrl-msm
devices.

Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Reported-by: Timur Tabi 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
   drivers/pinctrl/qcom/pinctrl-msm.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pinc
return -EINVAL;
chip = >chip;
-   chip->base = 0;
+   chip->base = -1;
chip->ngpio = ngpio;
chip->label = dev_name(pctrl->dev);
chip->parent = pctrl->dev;

this patch creates a regression for me. on ipq8064 the systems gpios now
start somewhere in the sky

new layout

lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip373 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip408 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip408
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip443 ->
../../devices/platform/soc/80.pinmux/gpio/gpiochip443


before the patch

lrwxrwxrwx    1 root root 0 Jan  1  1970 gpiochip0 ->
../../devices/platform/soc/80.pinmux/gpio/gpiochip0
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip442 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip477 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip477


this broke my userspace gpio handling. i can override this, but still it
doesnt look correct since there is a hole at the beginng likelly reserved by
unused arm gpios

So does this mean that 4.17-rc is also broken for you?  If so, this
needs to be reverted there as well.

Bjorn, any ideas?


The Qualcomm TLMM (pinctrl) driver was introduced long after it was
decided that the kernel should not rely on global/static gpio numbering.

But due to a mistake on my part the dynamic gpio base for this gpiochip
was always 0, which the offending patch corrects.


So writing user space code relying on the gpio numbering for this chip
has always been incorrect, just as it is for the other two gpiochips
listed above.


The original objection for backporting this patch was a touchscreen
driver stopped working on 4.4, but the driver clearly doesn't depend on
global or static numbering of gpios. I don't think this was ever root
caused.


I guess the pragmatic approach would be to come up with something like
Timur's suggested fix that makes the first instance of this driver use
base = 0 and then use dynamic numbering for the rest, to maintain
support for this incorrect usage of the gpio sysfs interface. (Although
that would probably break if Timur's customers move their user space to
the new platform as "the first instance" isn't deterministic).

Regards,
Bjorn

that would at least guarantee backward compatiblity. i'm fine with that

Sebastian

Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering

[Sebastian Gottschall]

Am 31.05.2018 um 14:12 schrieb Greg Kroah-Hartman:

On Thu, May 31, 2018 at 06:55:55AM -0500, Timur Tabi wrote:

On 5/31/18 6:53 AM, Sebastian Gottschall wrote:

i checked initially 4.9 with latest patches and 4.14 and reverted this
line to get back to the old behaviour but a which view in the current
4.17 tree shows
that the same patch has been included in 4.17. it was introduced in the
kernel mainline on 12.feb 2018
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/qcom/pinctrl-msm.c?h=v4.17-rc7=a7aa75a2a7dba32594291a71c3704000a2fd7089

I believe that this patch should not be applied to *any* stable kernel.

It completely breaks legacy GPIO numbering, and it does so intentionally.
That may be okay for future kernels, but IMHO it's wrong for older kernels.

Why is it somehow ok for "future" kernels?  You can't break the api in
the future for no reason.

So this needs to be the same everywhere.  If it is broken in 4.17-rc, it
needs to be reverted.

thanks,

greg k-h
i agree. i understand the reason why it was introduced, but the reason 
was a very special case which can be handled in a different way or 
specific for the affected architecture / device
and this patch alone cannot be introduced without further changes to 
device tree files which may assign those gpio numbers
i2c, leds etc. (a quick review of the current device tree files for qcom 
already showed me that they are likelly broken because of this change)


Sebastian

Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering

[Sebastian Gottschall]

Am 31.05.2018 um 14:12 schrieb Greg Kroah-Hartman:

On Thu, May 31, 2018 at 06:55:55AM -0500, Timur Tabi wrote:

On 5/31/18 6:53 AM, Sebastian Gottschall wrote:

i checked initially 4.9 with latest patches and 4.14 and reverted this
line to get back to the old behaviour but a which view in the current
4.17 tree shows
that the same patch has been included in 4.17. it was introduced in the
kernel mainline on 12.feb 2018
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/qcom/pinctrl-msm.c?h=v4.17-rc7=a7aa75a2a7dba32594291a71c3704000a2fd7089

I believe that this patch should not be applied to *any* stable kernel.

It completely breaks legacy GPIO numbering, and it does so intentionally.
That may be okay for future kernels, but IMHO it's wrong for older kernels.

Why is it somehow ok for "future" kernels?  You can't break the api in
the future for no reason.

So this needs to be the same everywhere.  If it is broken in 4.17-rc, it
needs to be reverted.

thanks,

greg k-h
i agree. i understand the reason why it was introduced, but the reason 
was a very special case which can be handled in a different way or 
specific for the affected architecture / device
and this patch alone cannot be introduced without further changes to 
device tree files which may assign those gpio numbers
i2c, leds etc. (a quick review of the current device tree files for qcom 
already showed me that they are likelly broken because of this change)


Sebastian

Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering

[Sebastian Gottschall]

Am 31.05.2018 um 13:45 schrieb Greg Kroah-Hartman:

On Thu, May 31, 2018 at 01:21:56PM +0200, Sebastian Gottschall wrote:

Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Andersson 

[ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]

The base of the TLMM gpiochip should not be statically defined as 0, fix
this to not artificially restrict the existence of multiple pinctrl-msm
devices.

Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Reported-by: Timur Tabi 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
   drivers/pinctrl/qcom/pinctrl-msm.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pinc
return -EINVAL;
chip = >chip;
-   chip->base = 0;
+   chip->base = -1;
chip->ngpio = ngpio;
chip->label = dev_name(pctrl->dev);
chip->parent = pctrl->dev;

this patch creates a regression for me. on ipq8064 the systems gpios now
start somewhere in the sky

new layout

lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip373 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip408 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip408
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip443 ->
../../devices/platform/soc/80.pinmux/gpio/gpiochip443


before the patch

lrwxrwxrwx    1 root root 0 Jan  1  1970 gpiochip0 ->
../../devices/platform/soc/80.pinmux/gpio/gpiochip0
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip442 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip477 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip477


this broke my userspace gpio handling. i can override this, but still it
doesnt look correct since there is a hole at the beginng likelly reserved by
unused arm gpios

So does this mean that 4.17-rc is also broken for you?  If so, this
needs to be reverted there as well.

Bjorn, any ideas?

thanks,

greg k-h
i checked initially 4.9 with latest patches and 4.14 and reverted this 
line to get back to the old behaviour but a which view in the current 
4.17 tree shows
that the same patch has been included in 4.17. it was introduced in the 
kernel mainline on 12.feb 2018

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/qcom/pinctrl-msm.c?h=v4.17-rc7=a7aa75a2a7dba32594291a71c3704000a2fd7089

Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering

[Sebastian Gottschall]

Am 31.05.2018 um 13:45 schrieb Greg Kroah-Hartman:

On Thu, May 31, 2018 at 01:21:56PM +0200, Sebastian Gottschall wrote:

Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Andersson 

[ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]

The base of the TLMM gpiochip should not be statically defined as 0, fix
this to not artificially restrict the existence of multiple pinctrl-msm
devices.

Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Reported-by: Timur Tabi 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
   drivers/pinctrl/qcom/pinctrl-msm.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pinc
return -EINVAL;
chip = >chip;
-   chip->base = 0;
+   chip->base = -1;
chip->ngpio = ngpio;
chip->label = dev_name(pctrl->dev);
chip->parent = pctrl->dev;

this patch creates a regression for me. on ipq8064 the systems gpios now
start somewhere in the sky

new layout

lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip373 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip408 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip408
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip443 ->
../../devices/platform/soc/80.pinmux/gpio/gpiochip443


before the patch

lrwxrwxrwx    1 root root 0 Jan  1  1970 gpiochip0 ->
../../devices/platform/soc/80.pinmux/gpio/gpiochip0
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip442 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip477 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip477


this broke my userspace gpio handling. i can override this, but still it
doesnt look correct since there is a hole at the beginng likelly reserved by
unused arm gpios

So does this mean that 4.17-rc is also broken for you?  If so, this
needs to be reverted there as well.

Bjorn, any ideas?

thanks,

greg k-h
i checked initially 4.9 with latest patches and 4.14 and reverted this 
line to get back to the old behaviour but a which view in the current 
4.17 tree shows
that the same patch has been included in 4.17. it was introduced in the 
kernel mainline on 12.feb 2018

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/qcom/pinctrl-msm.c?h=v4.17-rc7=a7aa75a2a7dba32594291a71c3704000a2fd7089

Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering

[Sebastian Gottschall]

Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Andersson 

[ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]

The base of the TLMM gpiochip should not be statically defined as 0, fix
this to not artificially restrict the existence of multiple pinctrl-msm
devices.

Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Reported-by: Timur Tabi 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
  drivers/pinctrl/qcom/pinctrl-msm.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pinc
return -EINVAL;
  
  	chip = >chip;

-   chip->base = 0;
+   chip->base = -1;
chip->ngpio = ngpio;
chip->label = dev_name(pctrl->dev);
chip->parent = pctrl->dev;


this patch creates a regression for me. on ipq8064 the systems gpios now 
start somewhere in the sky


new layout

lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip373 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip408 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip408
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip443 -> 
../../devices/platform/soc/80.pinmux/gpio/gpiochip443



before the patch

lrwxrwxrwx    1 root root 0 Jan  1  1970 gpiochip0 -> 
../../devices/platform/soc/80.pinmux/gpio/gpiochip0
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip442 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip477 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip477



this broke my userspace gpio handling. i can override this, but still it 
doesnt look correct since there is a hole at the beginng likelly 
reserved by unused arm gpios

Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering

[Sebastian Gottschall]

Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Bjorn Andersson 

[ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]

The base of the TLMM gpiochip should not be statically defined as 0, fix
this to not artificially restrict the existence of multiple pinctrl-msm
devices.

Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Reported-by: Timur Tabi 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
  drivers/pinctrl/qcom/pinctrl-msm.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pinc
return -EINVAL;
  
  	chip = >chip;

-   chip->base = 0;
+   chip->base = -1;
chip->ngpio = ngpio;
chip->label = dev_name(pctrl->dev);
chip->parent = pctrl->dev;


this patch creates a regression for me. on ipq8064 the systems gpios now 
start somewhere in the sky


new layout

lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip373 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip408 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip408
lrwxrwxrwx    1 root root 0 Jan  1 00:00 gpiochip443 -> 
../../devices/platform/soc/80.pinmux/gpio/gpiochip443



before the patch

lrwxrwxrwx    1 root root 0 Jan  1  1970 gpiochip0 -> 
../../devices/platform/soc/80.pinmux/gpio/gpiochip0
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip442 -> 
../../devices/platform/soc/1b70.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442
lrwxrwxrwx    1 root root 0 May 31 13:13 gpiochip477 -> 
../../devices/platform/soc/1b50.pci/pci:00/:00:00.0/:01:00.0/gpio/gpiochip477



this broke my userspace gpio handling. i can override this, but still it 
doesnt look correct since there is a hole at the beginng likelly 
reserved by unused arm gpios

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

easy answer from wikipedia. 224.0.x.x is not the only multicast block

AFAICT the code that was changed by this patch should not have
anything to do with other multicast blocks.  It generates an IGMPv3
report with destination address 224.0.0.22.  So it would be useful to
get more information on how exactly it is causing a failure, so we can
find the root cause.
from your code it always returns 0.0.0.0 and not the correct origin if 
your rule doesnt match. this is a different behaviour. before, the 
origin was used as is and not modified.
if the origin is set to zero, the routing of the network doesnt work 
anymore. this works for local multicast addresses, but not for neighbor 
networks which are using the routing table

but correct me if i'm wrong


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

easy answer from wikipedia. 224.0.x.x is not the only multicast block

AFAICT the code that was changed by this patch should not have
anything to do with other multicast blocks.  It generates an IGMPv3
report with destination address 224.0.0.22.  So it would be useful to
get more information on how exactly it is causing a failure, so we can
find the root cause.
from your code it always returns 0.0.0.0 and not the correct origin if 
your rule doesnt match. this is a different behaviour. before, the 
origin was used as is and not modified.
if the origin is set to zero, the routing of the network doesnt work 
anymore. this works for local multicast addresses, but not for neighbor 
networks which are using the routing table

but correct me if i'm wrong


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

Am 16.01.2018 um 16:25 schrieb David Miller:

From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>
Date: Tue, 16 Jan 2018 04:50:39 +0100


please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection
using igmp-proxy. reverting this patch fixes the issue.

Then should it be reverted in mainline as well?

yes


Please submit a proper report to the netdev list with the patch
author CC:'d explaining the situation exactly so that we can move
forweard.+

could ne author of the patch please handle that bureaucracy.
i mean, i wanted to let you know what my findings are, beside this i'm 
still a hard working developer. i integrated it into my own kernels and 
informed the openwrt/lede people already
i dont have time for hours of discussions. i explained earlier my 
thoughts about the cause of the fault in the patch. this should be enough
a more proper report would require deeper analyse and debugging of the 
problem which isnt really neccessary for 10 code lines from my point of view


Sebastian


Thank you.



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

Am 16.01.2018 um 16:25 schrieb David Miller:

From: Sebastian Gottschall 
Date: Tue, 16 Jan 2018 04:50:39 +0100


please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection
using igmp-proxy. reverting this patch fixes the issue.

Then should it be reverted in mainline as well?

yes


Please submit a proper report to the netdev list with the patch
author CC:'d explaining the situation exactly so that we can move
forweard.+

could ne author of the patch please handle that bureaucracy.
i mean, i wanted to let you know what my findings are, beside this i'm 
still a hard working developer. i integrated it into my own kernels and 
informed the openwrt/lede people already
i dont have time for hours of discussions. i explained earlier my 
thoughts about the cause of the fault in the patch. this should be enough
a more proper report would require deeper analyse and debugging of the 
problem which isnt really neccessary for 10 code lines from my point of view


Sebastian


Thank you.



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

in addition 224.0.0.x is not routable.
all other multicast addresses i showed you are routable. so your code  
will filter valid
multicast origins since they arent present on local interfaces. looks 
like your code only works valid for 224.0.0.x addresses but not any

other valid multicast address



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

in addition 224.0.0.x is not routable.
all other multicast addresses i showed you are routable. so your code  
will filter valid
multicast origins since they arent present on local interfaces. looks 
like your code only works valid for 224.0.0.x addresses but not any

other valid multicast address



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

According to my understanding of igmpv3_newpack(), the destination
address should always be IGMPV3_ALL_MCR = 224.0.0.22.  That is what I
see in my testing.

However, your packet trace says 239.35.100.8.  I don't know how the
code that we touched would be generating an IGMPv2 packet with that
destination address.

easy answer from wikipedia. 224.0.x.x is not the only multicast block

224.0.0.0 to 224.0.0.255 Local subnetwork
224.0.1.0 to 224.0.1.255 Internetwork control
224.0.2.0 to 224.0.255.255 AD-HOC block 1
224.3.0.0 to 224.4.255.255 AD-HOC block 2
232.0.0.0 to 232.255.255.255 Source-specific multicas
233.0.0.0 to 233.251.255.255 GLOP addressing
233.252.0.0 to 233.255.255.255 AD-HOC block 3
234.0.0.0 to 234.255.255.255 Unicast-prefix-based
239.0.0.0 to 239.255.255.255 Administratively scoped



Would it be possible to get a stack trace for the case where the
source address is being cleared to 0.0.0.0 in your configuration?

you mean something like dumpstack and watching the flood comes over me?


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

According to my understanding of igmpv3_newpack(), the destination
address should always be IGMPV3_ALL_MCR = 224.0.0.22.  That is what I
see in my testing.

However, your packet trace says 239.35.100.8.  I don't know how the
code that we touched would be generating an IGMPv2 packet with that
destination address.

easy answer from wikipedia. 224.0.x.x is not the only multicast block

224.0.0.0 to 224.0.0.255 Local subnetwork
224.0.1.0 to 224.0.1.255 Internetwork control
224.0.2.0 to 224.0.255.255 AD-HOC block 1
224.3.0.0 to 224.4.255.255 AD-HOC block 2
232.0.0.0 to 232.255.255.255 Source-specific multicas
233.0.0.0 to 233.251.255.255 GLOP addressing
233.252.0.0 to 233.255.255.255 AD-HOC block 3
234.0.0.0 to 234.255.255.255 Unicast-prefix-based
239.0.0.0 to 239.255.255.255 Administratively scoped



Would it be possible to get a stack trace for the case where the
source address is being cleared to 0.0.0.0 in your configuration?

you mean something like dumpstack and watching the flood comes over me?


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

Am 16.01.2018 um 06:55 schrieb Greg Kroah-Hartman:

On Tue, Jan 16, 2018 at 04:50:39AM +0100, Sebastian Gottschall wrote:

please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection using
igmp-proxy. reverting this patch fixes the issue.

So Linus's kernel also is broken for you?  Or does it work properly
there?^
all kernels are broken since 3th january. 3.18, 4.4, 4.9. 4.14 unless 
this patch is removed.

this can be verified with deutsche telekom iptv and igmp-proxy.
i just stumbled accross this issue recently while i updated my kernel 
source to latest revision. last working revision i tested with iptv was 
late december and iptv stopped working after updating.

so i stepped back until i found this small patch which did the magic

Sebastian


thanks,

greg k-h



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

Am 16.01.2018 um 06:55 schrieb Greg Kroah-Hartman:

On Tue, Jan 16, 2018 at 04:50:39AM +0100, Sebastian Gottschall wrote:

please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection using
igmp-proxy. reverting this patch fixes the issue.

So Linus's kernel also is broken for you?  Or does it work properly
there?^
all kernels are broken since 3th january. 3.18, 4.4, 4.9. 4.14 unless 
this patch is removed.

this can be verified with deutsche telekom iptv and igmp-proxy.
i just stumbled accross this issue recently while i updated my kernel 
source to latest revision. last working revision i tested with iptv was 
late december and iptv stopped working after updating.

so i stepped back until i found this small patch which did the magic

Sebastian


thanks,

greg k-h



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

3.18 and 4.4 is affected too

Am 16.01.2018 um 04:50 schrieb Sebastian Gottschall:

please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection 
using igmp-proxy. reverting this patch fixes the issue.


Sebastian



Am 01.01.2018 um 15:32 schrieb Greg Kroah-Hartman:
4.9-stable review patch.  If anyone has any objections, please let me 
know.


--

From: Kevin Cernekee <cerne...@chromium.org>


[ Upstream commit a46182b00290839fa3fa159d54fd3237bd8669f0 ]

Closing a multicast socket after the final IPv4 address is deleted
from an interface can generate a membership report that uses the
source IP from a different interface.  The following test script, run
from an isolated netns, reproduces the issue:

 #!/bin/bash

 ip link add dummy0 type dummy
 ip link add dummy1 type dummy
 ip link set dummy0 up
 ip link set dummy1 up
 ip addr add 10.1.1.1/24 dev dummy0
 ip addr add 192.168.99.99/24 dev dummy1

 tcpdump -U -i dummy0 &
 socat EXEC:"sleep 2" \
UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1 &

 sleep 1
 ip addr del 10.1.1.1/24 dev dummy0
 sleep 5
 kill %tcpdump

RFC 3376 specifies that the report must be sent with a valid IP source
address from the destination subnet, or from address 0.0.0.0. Add an
extra check to make sure this is the case.

Signed-off-by: Kevin Cernekee <cerne...@chromium.org>
Reviewed-by: Andrew Lunn <and...@lunn.ch>
Signed-off-by: David S. Miller <da...@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
  net/ipv4/igmp.c |   20 +++-
  1 file changed, 19 insertions(+), 1 deletion(-)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -89,6 +89,7 @@
  #include 
  #include 
  #include 
+#include 
    #include 
  #include 
@@ -321,6 +322,23 @@ igmp_scount(struct ip_mc_list *pmc, int
  return scount;
  }
  +/* source address selection per RFC 3376 section 4.2.13 */
+static __be32 igmpv3_get_srcaddr(struct net_device *dev,
+ const struct flowi4 *fl4)
+{
+    struct in_device *in_dev = __in_dev_get_rcu(dev);
+
+    if (!in_dev)
+    return htonl(INADDR_ANY);
+
+    for_ifa(in_dev) {
+    if (inet_ifa_match(fl4->saddr, ifa))
+    return fl4->saddr;
+    } endfor_ifa(in_dev);
+
+    return htonl(INADDR_ANY);
+}
+
  static struct sk_buff *igmpv3_newpack(struct net_device *dev, 
unsigned int mtu)

  {
  struct sk_buff *skb;
@@ -368,7 +386,7 @@ static struct sk_buff *igmpv3_newpack(st
  pip->frag_off = htons(IP_DF);
  pip->ttl  = 1;
  pip->daddr    = fl4.daddr;
-    pip->saddr    = fl4.saddr;
+    pip->saddr    = igmpv3_get_srcaddr(dev, );
  pip->protocol = IPPROTO_IGMP;
  pip->tot_len  = 0;    /* filled in later */
  ip_select_ident(net, skb, NULL);







--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

3.18 and 4.4 is affected too

Am 16.01.2018 um 04:50 schrieb Sebastian Gottschall:

please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection 
using igmp-proxy. reverting this patch fixes the issue.


Sebastian



Am 01.01.2018 um 15:32 schrieb Greg Kroah-Hartman:
4.9-stable review patch.  If anyone has any objections, please let me 
know.


--

From: Kevin Cernekee 


[ Upstream commit a46182b00290839fa3fa159d54fd3237bd8669f0 ]

Closing a multicast socket after the final IPv4 address is deleted
from an interface can generate a membership report that uses the
source IP from a different interface.  The following test script, run
from an isolated netns, reproduces the issue:

 #!/bin/bash

 ip link add dummy0 type dummy
 ip link add dummy1 type dummy
 ip link set dummy0 up
 ip link set dummy1 up
 ip addr add 10.1.1.1/24 dev dummy0
 ip addr add 192.168.99.99/24 dev dummy1

 tcpdump -U -i dummy0 &
 socat EXEC:"sleep 2" \
UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1 &

 sleep 1
 ip addr del 10.1.1.1/24 dev dummy0
 sleep 5
 kill %tcpdump

RFC 3376 specifies that the report must be sent with a valid IP source
address from the destination subnet, or from address 0.0.0.0. Add an
extra check to make sure this is the case.

Signed-off-by: Kevin Cernekee 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
  net/ipv4/igmp.c |   20 +++-
  1 file changed, 19 insertions(+), 1 deletion(-)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -89,6 +89,7 @@
  #include 
  #include 
  #include 
+#include 
    #include 
  #include 
@@ -321,6 +322,23 @@ igmp_scount(struct ip_mc_list *pmc, int
  return scount;
  }
  +/* source address selection per RFC 3376 section 4.2.13 */
+static __be32 igmpv3_get_srcaddr(struct net_device *dev,
+ const struct flowi4 *fl4)
+{
+    struct in_device *in_dev = __in_dev_get_rcu(dev);
+
+    if (!in_dev)
+    return htonl(INADDR_ANY);
+
+    for_ifa(in_dev) {
+    if (inet_ifa_match(fl4->saddr, ifa))
+    return fl4->saddr;
+    } endfor_ifa(in_dev);
+
+    return htonl(INADDR_ANY);
+}
+
  static struct sk_buff *igmpv3_newpack(struct net_device *dev, 
unsigned int mtu)

  {
  struct sk_buff *skb;
@@ -368,7 +386,7 @@ static struct sk_buff *igmpv3_newpack(st
  pip->frag_off = htons(IP_DF);
  pip->ttl  = 1;
  pip->daddr    = fl4.daddr;
-    pip->saddr    = fl4.saddr;
+    pip->saddr    = igmpv3_get_srcaddr(dev, );
  pip->protocol = IPPROTO_IGMP;
  pip->tot_len  = 0;    /* filled in later */
  ip_select_ident(net, skb, NULL);







--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

Am 16.01.2018 um 05:32 schrieb Kevin Cernekee:

On Mon, Jan 15, 2018 at 8:26 PM, Sebastian Gottschall
<s.gottsch...@dd-wrt.com> wrote:

havent check the source addresses right now. i basicly discovered that this
patch breaks the igmp routing and all traffic stops
this here is from a working system with the reverted patch. if you really
need that i break it again using the patch you need to wait a little bit

05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report 239.35.100.8

The patch should only affect IGMPv3 behavior.  I did not intend to
change IGMPv2 behavior.  If it does, that might be a bug.
it does change the behaviour indeed. i dont know the reason. but i while 
discovering the issue on 4.14 last week and newly on 4.9 this week while 
testing
(my latest firmware i builded was from 30. december and worked) i got 
tracked it down to this small patch and it immediatly worked after 
reverting it

Is it possible that the kernel is using a source IP of 0.0.0.0, but
another host does not recognize it because it does not comply with RFC
3376?

this is possible yes, but i cannot look into the "deutsche telekom" host


Before/after packet traces would be the best way to see if the kernel
change is causing it to violate the standard.

let me just take a look into our patch
+ for_ifa(in_dev) {
+ if (inet_ifa_match(fl4->saddr, ifa))
+ return fl4->saddr;
+ } endfor_ifa(in_dev);
this looks like you're checking if the source address matches to a local 
interface, if not you return 0.0.0.0 instead of the source address


(193.158.35.251, 239.35.20.4)    Iif: ppp0   Oifs: briptv

our first source address here 193.158.35.251 is from a remote network. 
so your patch also will change the behaviour since the source address 
will get ignored




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

Am 16.01.2018 um 05:32 schrieb Kevin Cernekee:

On Mon, Jan 15, 2018 at 8:26 PM, Sebastian Gottschall
 wrote:

havent check the source addresses right now. i basicly discovered that this
patch breaks the igmp routing and all traffic stops
this here is from a working system with the reverted patch. if you really
need that i break it again using the patch you need to wait a little bit

05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report 239.35.100.8

The patch should only affect IGMPv3 behavior.  I did not intend to
change IGMPv2 behavior.  If it does, that might be a bug.
it does change the behaviour indeed. i dont know the reason. but i while 
discovering the issue on 4.14 last week and newly on 4.9 this week while 
testing
(my latest firmware i builded was from 30. december and worked) i got 
tracked it down to this small patch and it immediatly worked after 
reverting it

Is it possible that the kernel is using a source IP of 0.0.0.0, but
another host does not recognize it because it does not comply with RFC
3376?

this is possible yes, but i cannot look into the "deutsche telekom" host


Before/after packet traces would be the best way to see if the kernel
change is causing it to violate the standard.

let me just take a look into our patch
+ for_ifa(in_dev) {
+ if (inet_ifa_match(fl4->saddr, ifa))
+ return fl4->saddr;
+ } endfor_ifa(in_dev);
this looks like you're checking if the source address matches to a local 
interface, if not you return 0.0.0.0 instead of the source address


(193.158.35.251, 239.35.20.4)    Iif: ppp0   Oifs: briptv

our first source address here 193.158.35.251 is from a remote network. 
so your patch also will change the behaviour since the source address 
will get ignored




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

Am 16.01.2018 um 04:58 schrieb Kevin Cernekee:

On Mon, Jan 15, 2018 at 7:50 PM, Sebastian Gottschall
<s.gottsch...@dd-wrt.com> wrote:

please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection using
igmp-proxy. reverting this patch fixes the issue.

Hi Sebastian,

Is this the correct igmp-proxy (based on mrouted)?

https://github.com/mirror/dd-wrt/tree/master/src/router/igmp-proxy

What is the actual vs. expected source address you are seeing on the
IGMP packets?
this github mirror is unmaintained. (svn.dd-wrt.com is the correct 
repository)

but yes, but same applies to upstream https://github.com/pali/igmpproxy

havent check the source addresses right now. i basicly discovered that 
this patch breaks the igmp routing and all traffic stops
this here is from a working system with the reverted patch. if you 
really need that i break it again using the patch you need to wait a 
little bit


05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report 239.35.100.8
root@shellfast:/proc/4032/net# /tmp/ip mroute
(193.158.35.251, 239.35.20.4)    Iif: ppp0   Oifs: briptv
(10.88.193.141, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.193.145, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.195.138, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.195.129, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.193.134, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.195.1, 239.255.255.250)   Iif: ppp0   Oifs: briptv
(10.88.193.109, 239.255.255.250) Iif: ppp0   Oifs: br0
(10.88.193.145, 239.192.152.143) Iif: ppp0   Oifs: br0
(10.88.193.1, 239.255.255.250)   Iif: ppp0   Oifs: br0





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

Am 16.01.2018 um 04:58 schrieb Kevin Cernekee:

On Mon, Jan 15, 2018 at 7:50 PM, Sebastian Gottschall
 wrote:

please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection using
igmp-proxy. reverting this patch fixes the issue.

Hi Sebastian,

Is this the correct igmp-proxy (based on mrouted)?

https://github.com/mirror/dd-wrt/tree/master/src/router/igmp-proxy

What is the actual vs. expected source address you are seeing on the
IGMP packets?
this github mirror is unmaintained. (svn.dd-wrt.com is the correct 
repository)

but yes, but same applies to upstream https://github.com/pali/igmpproxy

havent check the source addresses right now. i basicly discovered that 
this patch breaks the igmp routing and all traffic stops
this here is from a working system with the reverted patch. if you 
really need that i break it again using the patch you need to wait a 
little bit


05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report 239.35.100.8
root@shellfast:/proc/4032/net# /tmp/ip mroute
(193.158.35.251, 239.35.20.4)    Iif: ppp0   Oifs: briptv
(10.88.193.141, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.193.145, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.195.138, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.195.129, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.193.134, 239.255.255.250) Iif: ppp0   Oifs: briptv
(10.88.195.1, 239.255.255.250)   Iif: ppp0   Oifs: briptv
(10.88.193.109, 239.255.255.250) Iif: ppp0   Oifs: br0
(10.88.193.145, 239.192.152.143) Iif: ppp0   Oifs: br0
(10.88.193.1, 239.255.255.250)   Iif: ppp0   Oifs: br0





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection 
using igmp-proxy. reverting this patch fixes the issue.


Sebastian



Am 01.01.2018 um 15:32 schrieb Greg Kroah-Hartman:

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Kevin Cernekee <cerne...@chromium.org>


[ Upstream commit a46182b00290839fa3fa159d54fd3237bd8669f0 ]

Closing a multicast socket after the final IPv4 address is deleted
from an interface can generate a membership report that uses the
source IP from a different interface.  The following test script, run
from an isolated netns, reproduces the issue:

 #!/bin/bash

 ip link add dummy0 type dummy
 ip link add dummy1 type dummy
 ip link set dummy0 up
 ip link set dummy1 up
 ip addr add 10.1.1.1/24 dev dummy0
 ip addr add 192.168.99.99/24 dev dummy1

 tcpdump -U -i dummy0 &
 socat EXEC:"sleep 2" \
 UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1 &

 sleep 1
 ip addr del 10.1.1.1/24 dev dummy0
 sleep 5
 kill %tcpdump

RFC 3376 specifies that the report must be sent with a valid IP source
address from the destination subnet, or from address 0.0.0.0.  Add an
extra check to make sure this is the case.

Signed-off-by: Kevin Cernekee <cerne...@chromium.org>
Reviewed-by: Andrew Lunn <and...@lunn.ch>
Signed-off-by: David S. Miller <da...@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
  net/ipv4/igmp.c |   20 +++-
  1 file changed, 19 insertions(+), 1 deletion(-)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -89,6 +89,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -321,6 +322,23 @@ igmp_scount(struct ip_mc_list *pmc, int
return scount;
  }
  
+/* source address selection per RFC 3376 section 4.2.13 */

+static __be32 igmpv3_get_srcaddr(struct net_device *dev,
+const struct flowi4 *fl4)
+{
+   struct in_device *in_dev = __in_dev_get_rcu(dev);
+
+   if (!in_dev)
+   return htonl(INADDR_ANY);
+
+   for_ifa(in_dev) {
+   if (inet_ifa_match(fl4->saddr, ifa))
+   return fl4->saddr;
+   } endfor_ifa(in_dev);
+
+   return htonl(INADDR_ANY);
+}
+
  static struct sk_buff *igmpv3_newpack(struct net_device *dev, unsigned int 
mtu)
  {
struct sk_buff *skb;
@@ -368,7 +386,7 @@ static struct sk_buff *igmpv3_newpack(st
pip->frag_off = htons(IP_DF);
pip->ttl  = 1;
pip->daddr= fl4.daddr;
-   pip->saddr= fl4.saddr;
+   pip->saddr= igmpv3_get_srcaddr(dev, );
pip->protocol = IPPROTO_IGMP;
pip->tot_len  = 0;   /* filled in later */
ip_select_ident(net, skb, NULL);





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

[Sebastian Gottschall]

please revert that on 4.9 and 4.14
it breaks igmp routing. it can be reproduced with any iptv connection 
using igmp-proxy. reverting this patch fixes the issue.


Sebastian



Am 01.01.2018 um 15:32 schrieb Greg Kroah-Hartman:

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Kevin Cernekee 


[ Upstream commit a46182b00290839fa3fa159d54fd3237bd8669f0 ]

Closing a multicast socket after the final IPv4 address is deleted
from an interface can generate a membership report that uses the
source IP from a different interface.  The following test script, run
from an isolated netns, reproduces the issue:

 #!/bin/bash

 ip link add dummy0 type dummy
 ip link add dummy1 type dummy
 ip link set dummy0 up
 ip link set dummy1 up
 ip addr add 10.1.1.1/24 dev dummy0
 ip addr add 192.168.99.99/24 dev dummy1

 tcpdump -U -i dummy0 &
 socat EXEC:"sleep 2" \
 UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1 &

 sleep 1
 ip addr del 10.1.1.1/24 dev dummy0
 sleep 5
 kill %tcpdump

RFC 3376 specifies that the report must be sent with a valid IP source
address from the destination subnet, or from address 0.0.0.0.  Add an
extra check to make sure this is the case.

Signed-off-by: Kevin Cernekee 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
  net/ipv4/igmp.c |   20 +++-
  1 file changed, 19 insertions(+), 1 deletion(-)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -89,6 +89,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -321,6 +322,23 @@ igmp_scount(struct ip_mc_list *pmc, int
return scount;
  }
  
+/* source address selection per RFC 3376 section 4.2.13 */

+static __be32 igmpv3_get_srcaddr(struct net_device *dev,
+const struct flowi4 *fl4)
+{
+   struct in_device *in_dev = __in_dev_get_rcu(dev);
+
+   if (!in_dev)
+   return htonl(INADDR_ANY);
+
+   for_ifa(in_dev) {
+   if (inet_ifa_match(fl4->saddr, ifa))
+   return fl4->saddr;
+   } endfor_ifa(in_dev);
+
+   return htonl(INADDR_ANY);
+}
+
  static struct sk_buff *igmpv3_newpack(struct net_device *dev, unsigned int 
mtu)
  {
struct sk_buff *skb;
@@ -368,7 +386,7 @@ static struct sk_buff *igmpv3_newpack(st
pip->frag_off = htons(IP_DF);
pip->ttl  = 1;
pip->daddr= fl4.daddr;
-   pip->saddr= fl4.saddr;
+   pip->saddr= igmpv3_get_srcaddr(dev, );
pip->protocol = IPPROTO_IGMP;
pip->tot_len  = 0;   /* filled in later */
ip_select_ident(net, skb, NULL);





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: 4.14.9 doesn't boot (regression)

[Sebastian Gottschall]

bootlog?

Am 29.12.2017 um 12:14 schrieb Toralf Förster:

I can confirm now, that that kernel breaks both a desktop (an ThinkPad T440s 
i5) and a headless server (i3930) setup. For the server the attached .config 
works fine but switching from CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them 
hang at boot w/op any messages. Similar picture at the desktop.
Both are stable Gentoo Linux hardened systems.

This issue seems to exist in mainline too, probably visible with d120cd749 
(stable) and 9aaefe7b59 (upstream).



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: 4.14.9 doesn't boot (regression)

[Sebastian Gottschall]

bootlog?

Am 29.12.2017 um 12:14 schrieb Toralf Förster:

I can confirm now, that that kernel breaks both a desktop (an ThinkPad T440s 
i5) and a headless server (i3930) setup. For the server the attached .config 
works fine but switching from CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them 
hang at boot w/op any messages. Similar picture at the desktop.
Both are stable Gentoo Linux hardened systems.

This issue seems to exist in mainline too, probably visible with d120cd749 
(stable) and 9aaefe7b59 (upstream).



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 3.18 00/64] 3.18.88-stable review

[Sebastian Gottschall]

| 10 ++--
  kernel/debug/kdb/kdb_io.c|  2 +-
  kernel/workqueue.c   |  1 +
  lib/asn1_decoder.c   |  2 +
  lib/dynamic_debug.c  |  4 ++
  lib/genalloc.c   | 10 ++--
  net/ipv4/route.c | 14 +++--
  net/ipv6/af_inet6.c  | 10 ++--
  net/ipv6/sit.c   |  1 +
  net/packet/af_packet.c   |  5 ++
  net/rds/rdma.c   |  2 +-
  net/sctp/socket.c| 38 -
  net/sunrpc/sched.c   |  3 +-
  net/xfrm/xfrm_policy.c   |  1 +
  security/keys/request_key.c  | 46 +---
  sound/core/pcm.c |  2 +
  sound/core/seq/seq_timer.c   |  2 +-
  sound/usb/mixer.c| 13 +++--
  tools/hv/hv_kvp_daemon.c | 70 +---
  tools/testing/selftests/powerpc/harness.c|  6 +-
  61 files changed, 288 insertions(+), 200 deletions(-)





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 3.18 00/64] 3.18.88-stable review

[Sebastian Gottschall]

s from KVP file

weiping zhang 
 virtio: release virtio index when fail to device_register

Martin Kelly 
 can: usb_8dev: cancel urb on -EPIPE and -EPROTO

Martin Kelly 
 can: esd_usb2: cancel urb on -EPIPE and -EPROTO

Martin Kelly 
 can: ems_usb: cancel urb on -EPIPE and -EPROTO

Martin Kelly 
 can: kvaser_usb: cancel urb on -EPIPE and -EPROTO

Jimmy Assarsson 
 can: kvaser_usb: ratelimit errors if incomplete messages are received

Jimmy Assarsson 
 can: kvaser_usb: Fix comparison bug in kvaser_usb_read_bulk_callback()

Jimmy Assarsson 
 can: kvaser_usb: free buf in error paths


-

Diffstat:

  Makefile |  4 +-
  arch/arm/include/asm/kvm_arm.h   |  4 +-
  arch/arm/kvm/handle_exit.c   | 19 ---
  arch/arm64/include/asm/kvm_arm.h |  3 +-
  arch/arm64/kernel/process.c  |  9 +++
  arch/powerpc/sysdev/axonram.c|  5 +-
  arch/s390/include/asm/asm-prototypes.h   |  8 ---
  arch/sparc/mm/init_64.c  |  9 ++-
  arch/x86/kvm/vmx.c   |  9 +--
  arch/x86/pci/broadcom_bus.c  |  2 +-
  crypto/asymmetric_keys/x509_cert_parser.c|  2 +
  drivers/ata/libata-sff.c |  1 -
  drivers/atm/horizon.c|  2 +-
  drivers/base/isa.c   | 10 ++--
  drivers/crypto/s5p-sss.c |  5 +-
  drivers/edac/i5000_edac.c|  8 +--
  drivers/edac/i5400_edac.c|  9 +--
  drivers/firmware/efi/efi.c   |  3 +-
  drivers/firmware/efi/runtime-map.c   | 10 ++--
  drivers/gpu/drm/armada/Makefile  |  2 -
  drivers/i2c/busses/i2c-riic.c|  6 +-
  drivers/infiniband/hw/mlx4/qp.c  |  2 +-
  drivers/infiniband/hw/mlx5/main.c|  2 +
  drivers/iommu/intel-iommu.c  |  8 ++-
  drivers/irqchip/irq-crossbar.c   |  8 +--
  drivers/media/usb/dvb-usb/dibusb-common.c| 16 +-
  drivers/net/can/usb/ems_usb.c|  2 +
  drivers/net/can/usb/esd_usb2.c   |  2 +
  drivers/net/can/usb/kvaser_usb.c | 13 +++--
  drivers/net/can/usb/usb_8dev.c   |  2 +
  drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 23 
  drivers/net/phy/spi_ks8995.c |  1 +
  drivers/scsi/lpfc/lpfc_els.c | 14 +++--
  drivers/usb/gadget/configfs.c|  1 +
  drivers/usb/gadget/function/f_fs.c   |  2 +-
  drivers/usb/gadget/legacy/inode.c|  4 +-
  drivers/virtio/virtio.c  |  2 +
  fs/afs/cmservice.c   |  3 +
  fs/nfs/dir.c |  2 +-
  include/linux/genalloc.h |  3 +-
  include/linux/sysfs.h|  6 ++
  kernel/audit.c   | 10 ++--
  kernel/debug/kdb/kdb_io.c|  2 +-
  kernel/workqueue.c   |  1 +
  lib/asn1_decoder.c   |  2 +
  lib/dynamic_debug.c  |  4 ++
  lib/genalloc.c   | 10 ++--
  net/ipv4/route.c | 14 +++--
  net/ipv6/af_inet6.c  | 10 ++--
  net/ipv6/sit.c   |  1 +
  net/packet/af_packet.c   |  5 ++
  net/rds/rdma.c   |  2 +-
  net/sctp/socket.c| 38 -
  net/sunrpc/sched.c   |  3 +-
  net/xfrm/xfrm_policy.c   |  1 +
  security/keys/request_key.c  | 46 +---
  sound/core/pcm.c |  2 +
  sound/core/seq/seq_timer.c   |  2 +-
  sound/usb/mixer.c| 13 +++--
  tools/hv/hv_kvp_daemon.c | 70 +---
  tools/testing/selftests/powerpc/harness.c|  6 +-
  61 files changed, 288 insertions(+), 200 deletions(-)





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 4.9.69

[Sebastian Gottschall]

ignore the report. cause was a private driver fault which was triggered 
by the update


Am 14.12.2017 um 22:07 schrieb Sebastian Gottschall:

Am 14.12.2017 um 21:01 schrieb Greg KH:

On Thu, Dec 14, 2017 at 08:20:08PM +0100, Sebastian Gottschall wrote:
this happend with the rc1 version. dont know if it still applies, 
will check

now. 4.9.68 works

[    2.523730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.69-rc1 #16
[    2.523823] Hardware name: Qualcomm (Flattened Device Tree)
[    2.530247] task: dd41a9c0 task.stack: dd434000
[    2.535548] PC is at llc_sap_open+0x34/0xf8
[    2.540053] LR is at llc_sap_open+0x28/0xf8

Odd, nothing has changed in this area since 4.9.13.

Any chance you can run 'git bisect' to find the offending commit?
im currently heavily debugging and looking for the cause of the 
problem. seems to be a corrupt rcu list


thanks,

greg k-h





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 4.9.69

[Sebastian Gottschall]

ignore the report. cause was a private driver fault which was triggered 
by the update


Am 14.12.2017 um 22:07 schrieb Sebastian Gottschall:

Am 14.12.2017 um 21:01 schrieb Greg KH:

On Thu, Dec 14, 2017 at 08:20:08PM +0100, Sebastian Gottschall wrote:
this happend with the rc1 version. dont know if it still applies, 
will check

now. 4.9.68 works

[    2.523730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.69-rc1 #16
[    2.523823] Hardware name: Qualcomm (Flattened Device Tree)
[    2.530247] task: dd41a9c0 task.stack: dd434000
[    2.535548] PC is at llc_sap_open+0x34/0xf8
[    2.540053] LR is at llc_sap_open+0x28/0xf8

Odd, nothing has changed in this area since 4.9.13.

Any chance you can run 'git bisect' to find the offending commit?
im currently heavily debugging and looking for the cause of the 
problem. seems to be a corrupt rcu list


thanks,

greg k-h





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 4.9.69

[Sebastian Gottschall]

Am 14.12.2017 um 21:01 schrieb Greg KH:

On Thu, Dec 14, 2017 at 08:20:08PM +0100, Sebastian Gottschall wrote:

this happend with the rc1 version. dont know if it still applies, will check
now. 4.9.68 works

[    2.523730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.69-rc1 #16
[    2.523823] Hardware name: Qualcomm (Flattened Device Tree)
[    2.530247] task: dd41a9c0 task.stack: dd434000
[    2.535548] PC is at llc_sap_open+0x34/0xf8
[    2.540053] LR is at llc_sap_open+0x28/0xf8

Odd, nothing has changed in this area since 4.9.13.

Any chance you can run 'git bisect' to find the offending commit?
im currently heavily debugging and looking for the cause of the problem. 
seems to be a corrupt rcu list


thanks,

greg k-h



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 4.9.69

[Sebastian Gottschall]

Am 14.12.2017 um 21:01 schrieb Greg KH:

On Thu, Dec 14, 2017 at 08:20:08PM +0100, Sebastian Gottschall wrote:

this happend with the rc1 version. dont know if it still applies, will check
now. 4.9.68 works

[    2.523730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.69-rc1 #16
[    2.523823] Hardware name: Qualcomm (Flattened Device Tree)
[    2.530247] task: dd41a9c0 task.stack: dd434000
[    2.535548] PC is at llc_sap_open+0x34/0xf8
[    2.540053] LR is at llc_sap_open+0x28/0xf8

Odd, nothing has changed in this area since 4.9.13.

Any chance you can run 'git bisect' to find the offending commit?
im currently heavily debugging and looking for the cause of the problem. 
seems to be a corrupt rcu list


thanks,

greg k-h



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 4.9.69

[Sebastian Gottschall]

e did not configure

Ming Lei (2):
   blk-mq: initialize mq kobjects in blk_mq_init_allocated_queue()
   block: wake up all tasks blocked in get_request()

Nicholas Piggin (2):
   powerpc/64s: Initialize ISAv3 MMU registers before setting partition 
table
   powerpc: Fix compiling a BE kernel with a powerpc64le toolchain

Oliver Stäbler (1):
   can: ti_hecc: Fix napi poll return value for repoll

Pan Bian (1):
   efi/esrt: Use memunmap() instead of kfree() to free the remapping

Paul Mackerras (1):
   powerpc/64: Invalidate process table caching after setting process table

Paul Meyer (1):
   hv: kvp: Avoid reading past allocated blocks from KVP file

Pavel Tatashin (1):
   sparc64/mm: set fields in deferred pages

Peter Zijlstra (1):
   sched/fair: Make select_idle_cpu() more aggressive

Petr Cvek (1):
   usb: gadget: pxa27x: Test for a valid argument pointer

Phil Reid (1):
   gpio: altera: Use handle_level_irq when configured as a level_high

Radim Krčmář (1):
   KVM: x86: fix APIC page invalidation

Rafael J. Wysocki (1):
   x86/PCI: Make broadcom_postcore_init() check acpi_disabled

Randy Dunlap (1):
   dynamic-debug-howto: fix optional/omitted ending line number to be LARGE 
instead of 0

Raz Manor (1):
   usb: gadget: udc: net2280: Fix tmp reusage in net2280 driver

Robb Glasser (1):
   ALSA: pcm: prevent UAF in snd_pcm_info

Robin Murphy (1):
   iommu/vt-d: Fix scatterlist offset handling

Roger Quadros (1):
   usb: dwc3: gadget: Fix system suspend/resume on TI platforms

Russell King (2):
   ARM: BUG if jumping to usermode address in kernel mode
   ARM: avoid faulting on qemu

Sachin Sant (1):
   selftest/powerpc: Fix false failures for skipped tests

Sasha Levin (2):
   Revert "drm/armada: Fix compile fail"
   Revert "spi: SPI_FSL_DSPI should depend on HAS_DMA"

Sean Young (1):
   lirc: fix dead lock between open and wakeup_filter

Sergey Senozhatsky (1):
   zsmalloc: calling zs_map_object() from irq is a bug

Shile Zhang (1):
   powerpc/64: Fix checksum folding in csum_add()

Sowmini Varadhan (1):
   rds: tcp: Sequence teardown of listen and acceptor sockets to avoid races

Steffen Klassert (1):
   vti6: Don't report path MTU below IPV6_MIN_MTU.

Stephen Bates (1):
   lib/genalloc.c: make the avail variable an atomic_long_t

Takashi Iwai (1):
   ALSA: seq: Remove spurious WARN_ON() at timer check

Tejun Heo (2):
   libata: drop WARN from protocol error in ata_sff_qc_issue()
   workqueue: trigger WARN if queue_delayed_work() is called with NULL @wq

Thomas Falcon (2):
   ibmvnic: Fix overflowing firmware/hardware TX queue
   ibmvnic: Allocate number of rx/tx buffers agreed on by firmware

Thomas Gleixner (1):
   x86/hpet: Prevent might sleep splat on resume

Trond Myklebust (1):
   NFS: Fix a typo in nfs_rename()

WANG Cong (1):
   ipv6: reorder icmpv6_init() and ip6_mr_init()

Wanpeng Li (1):
   KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset

William Breathitt Gray (1):
   isa: Prevent NULL dereference in isa_bus driver callbacks

Xin Long (4):
   route: also update fnhe_genid when updating a route cache
   route: update fnhe_expires for redirect when the fnhe exists
   sctp: do not free asoc when it is already dead in sctp_sendmsg
   sctp: use the right sk after waking up from wait_buf sleep

Yoshihiro Shimoda (1):
   usb: gadget: udc: renesas_usb3: fix number of the pipes

weiping zhang (1):
   virtio: release virtio index when fail to device_register



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 4.9.69

[Sebastian Gottschall]

e did not configure

Ming Lei (2):
   blk-mq: initialize mq kobjects in blk_mq_init_allocated_queue()
   block: wake up all tasks blocked in get_request()

Nicholas Piggin (2):
   powerpc/64s: Initialize ISAv3 MMU registers before setting partition 
table
   powerpc: Fix compiling a BE kernel with a powerpc64le toolchain

Oliver Stäbler (1):
   can: ti_hecc: Fix napi poll return value for repoll

Pan Bian (1):
   efi/esrt: Use memunmap() instead of kfree() to free the remapping

Paul Mackerras (1):
   powerpc/64: Invalidate process table caching after setting process table

Paul Meyer (1):
   hv: kvp: Avoid reading past allocated blocks from KVP file

Pavel Tatashin (1):
   sparc64/mm: set fields in deferred pages

Peter Zijlstra (1):
   sched/fair: Make select_idle_cpu() more aggressive

Petr Cvek (1):
   usb: gadget: pxa27x: Test for a valid argument pointer

Phil Reid (1):
   gpio: altera: Use handle_level_irq when configured as a level_high

Radim Krčmář (1):
   KVM: x86: fix APIC page invalidation

Rafael J. Wysocki (1):
   x86/PCI: Make broadcom_postcore_init() check acpi_disabled

Randy Dunlap (1):
   dynamic-debug-howto: fix optional/omitted ending line number to be LARGE 
instead of 0

Raz Manor (1):
   usb: gadget: udc: net2280: Fix tmp reusage in net2280 driver

Robb Glasser (1):
   ALSA: pcm: prevent UAF in snd_pcm_info

Robin Murphy (1):
   iommu/vt-d: Fix scatterlist offset handling

Roger Quadros (1):
   usb: dwc3: gadget: Fix system suspend/resume on TI platforms

Russell King (2):
   ARM: BUG if jumping to usermode address in kernel mode
   ARM: avoid faulting on qemu

Sachin Sant (1):
   selftest/powerpc: Fix false failures for skipped tests

Sasha Levin (2):
   Revert "drm/armada: Fix compile fail"
   Revert "spi: SPI_FSL_DSPI should depend on HAS_DMA"

Sean Young (1):
   lirc: fix dead lock between open and wakeup_filter

Sergey Senozhatsky (1):
   zsmalloc: calling zs_map_object() from irq is a bug

Shile Zhang (1):
   powerpc/64: Fix checksum folding in csum_add()

Sowmini Varadhan (1):
   rds: tcp: Sequence teardown of listen and acceptor sockets to avoid races

Steffen Klassert (1):
   vti6: Don't report path MTU below IPV6_MIN_MTU.

Stephen Bates (1):
   lib/genalloc.c: make the avail variable an atomic_long_t

Takashi Iwai (1):
   ALSA: seq: Remove spurious WARN_ON() at timer check

Tejun Heo (2):
   libata: drop WARN from protocol error in ata_sff_qc_issue()
   workqueue: trigger WARN if queue_delayed_work() is called with NULL @wq

Thomas Falcon (2):
   ibmvnic: Fix overflowing firmware/hardware TX queue
   ibmvnic: Allocate number of rx/tx buffers agreed on by firmware

Thomas Gleixner (1):
   x86/hpet: Prevent might sleep splat on resume

Trond Myklebust (1):
   NFS: Fix a typo in nfs_rename()

WANG Cong (1):
   ipv6: reorder icmpv6_init() and ip6_mr_init()

Wanpeng Li (1):
   KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset

William Breathitt Gray (1):
   isa: Prevent NULL dereference in isa_bus driver callbacks

Xin Long (4):
   route: also update fnhe_genid when updating a route cache
   route: update fnhe_expires for redirect when the fnhe exists
   sctp: do not free asoc when it is already dead in sctp_sendmsg
   sctp: use the right sk after waking up from wait_buf sleep

Yoshihiro Shimoda (1):
   usb: gadget: udc: renesas_usb3: fix number of the pipes

weiping zhang (1):
   virtio: release virtio index when fail to device_register



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 3.10.108 (EOL)

[Sebastian Gottschall]

Am 18.11.2017 um 00:46 schrieb Alan Cox:

i just wanted to throw some stones on the bloated kernel problem which is
increasing

People used to be working on that, but then it seemed like the "size"
got to a point that people were comfortable with it.  Are you sure that

There's also a lot of pushback to things that add a ton of ifdefs.


just changing some build options would not make your image smaller?
Letting people know sometime in the past few years that the kernel was
getting "too big" for you would have been good to do :)

It's also an increasingly hard problem to deal with because the scale of
big machines means the algorithms themselves in a modern Linux OS just
don't make sense for a tiddly embedded router.

I know lots of people build them that way but if you compare it with one
of the more conservative *BSD builds you have to wonder why not use BSD
instead - especially with nanoBSD ?

(and BSD has the reverse problem - most BSD does not scale to a modern
bigger machine of course).

Alan
"1.2.13 was the last true Linux"  ;-)



easy. i have to port alot of cpu platforms to bsd then and since i'm doing

wireless routers i will run into a problem with all the drivers i have 
to rewrite for bsd and the bsd wireless stack is simply shit


its basicly a impossible task. and most of my code is gpl licensed. mmh 
mixing with bsd code, not a good idea



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 3.10.108 (EOL)

[Sebastian Gottschall]

Am 18.11.2017 um 00:46 schrieb Alan Cox:

i just wanted to throw some stones on the bloated kernel problem which is
increasing

People used to be working on that, but then it seemed like the "size"
got to a point that people were comfortable with it.  Are you sure that

There's also a lot of pushback to things that add a ton of ifdefs.


just changing some build options would not make your image smaller?
Letting people know sometime in the past few years that the kernel was
getting "too big" for you would have been good to do :)

It's also an increasingly hard problem to deal with because the scale of
big machines means the algorithms themselves in a modern Linux OS just
don't make sense for a tiddly embedded router.

I know lots of people build them that way but if you compare it with one
of the more conservative *BSD builds you have to wonder why not use BSD
instead - especially with nanoBSD ?

(and BSD has the reverse problem - most BSD does not scale to a modern
bigger machine of course).

Alan
"1.2.13 was the last true Linux"  ;-)



easy. i have to port alot of cpu platforms to bsd then and since i'm doing

wireless routers i will run into a problem with all the drivers i have 
to rewrite for bsd and the bsd wireless stack is simply shit


its basicly a impossible task. and most of my code is gpl licensed. mmh 
mixing with bsd code, not a good idea



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 3.10.108 (EOL)

[Sebastian Gottschall]

Am 15.11.2017 um 05:32 schrieb Willy Tarreau:

On Tue, Nov 14, 2017 at 11:40:31PM +0100, Sebastian Gottschall wrote:

And anyway the end of life has been indicated on kernel.org for 18 months
and in every announce in 2017, so it cannot be a surprize anymore :-) At
least nobody seemed to complain for all this time!

itsn no surprise for sure, but that also means i have to stay on the old
kernel for these special devices and your argument about disable certain
parts which simply turned bigger over time is no option

since it would remove features which existed before. its not that i enable
all features of the kernel. i use every kernel with the same options (some
are adjusted since they are renamed or moved)

Then I have a few questions :
   - how did you choose this kernel ? Or did you choose the hardware based
 on the kernel size ?


i did not choose it. i port regular all kernels to the platforms i use 
including 4.4 and 4.9


but a few of these which are already ported to 4.4 and 4.9 will still 
run 3.10 for resource problems.



   - what would have you done if 3.10 had not been LTS ?

using another LTS at that point :-)

   - have you at least tried other kernels before claiming they are much
 larger ? Following your principle, 3.2 should be smaller and 3.16 not
 much larger. The former offers you about 6 extra months of maintenance,
 the latter 3.5 years (https://www.kernel.org/category/releases.html).


i also used 3.2 before. sure

dont get me wrong i work with all kernels, also with latests. i do also 
not complain that 3.10 is now EOL


i just wanted to throw some stones on the bloated kernel problem which 
is increasing





but even then the kernel is turning into a ram and space eating monster if i
look on devices with 16 mb ram and 4 mb flash. this is mainly for
maintaining older hardware with latest updates.

So why didn't you ask if it was possible to pursue the maintenance a bit a
long time ago ? LTS maintenance is a collective effort and is done based on
usage. If enough people have good reasons for going further it can be enough
a justification to push the deadline. Now it's too late.


didnt know that. the LTS deadline was defined a long time ago. i follow 
up the mailing lists mainly for reviewing patches


and reporting feedback if required. if it see such a discussion i may 
get in touch with it too, but with hundrets of emails every days here 
its hard to follow anything



the more recent hardware is getting better here

you dont seem to know how it is to work on wireless routers :-)

Yes I do, I've been distributing a full blown load balancer distro on a
10 MB image (running on 3.10 as well). But I also know that sometimes
you make some nice space savings on new kernels (xz/zstd compression,
ability to remove certain useless stuff in these environments such as
FS ACLs or mandatory locks, etc). Sure, upgrading to a new kernel on
existing hardware is always a challenge. But it's also an interesting
one.


i do use xz and i do use a modified squashfs which is even smaller than 
the xz one in the kernel


smallest router i run with linux has 8 mb ram and 2 mb flash. so i do 
know how to get all very small. 10 mb image is no issue for me. the 4 mb 
flashes devices are my problem.





Also just to give you an idea, I've just compared the size of these
kernels configured with "make allnoconfig" (and I verified that all
of them were compressed using gzip) :

   3.10.108 : 875 kB
   4.4.97   : 522 kB
   4.9.61   : 561 kB
   4.14 : 566 kB


its a little bit unrealistic since you have to count in network 
subsystem, filesystem and drivers.


standard kernel with xz compression is about 800 - 900 kb for me in 3.10 
and 4.4 / 4.9 etc. is often more than 1 - 1.2 mb


sometimes just the 100 kb more count in and turn into a problem since i 
have to remove something from the image to get it fitting


if you are really interested i can give you a real comparisation using a 
comparable config on 3.10, 4.4 and 4.9 for a standard mips target




So the argument that migrating away from 3.10 is hard due to the size
doesn't stand much here :-)
its turning harder. i already ported 4.4 and 4.9 as i said. so i tried 
already if they are running or not. they do run, but they are bigger and 
do not fit for some targets


Willy



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 3.10.108 (EOL)

[Sebastian Gottschall]

Am 15.11.2017 um 05:32 schrieb Willy Tarreau:

On Tue, Nov 14, 2017 at 11:40:31PM +0100, Sebastian Gottschall wrote:

And anyway the end of life has been indicated on kernel.org for 18 months
and in every announce in 2017, so it cannot be a surprize anymore :-) At
least nobody seemed to complain for all this time!

itsn no surprise for sure, but that also means i have to stay on the old
kernel for these special devices and your argument about disable certain
parts which simply turned bigger over time is no option

since it would remove features which existed before. its not that i enable
all features of the kernel. i use every kernel with the same options (some
are adjusted since they are renamed or moved)

Then I have a few questions :
   - how did you choose this kernel ? Or did you choose the hardware based
 on the kernel size ?


i did not choose it. i port regular all kernels to the platforms i use 
including 4.4 and 4.9


but a few of these which are already ported to 4.4 and 4.9 will still 
run 3.10 for resource problems.



   - what would have you done if 3.10 had not been LTS ?

using another LTS at that point :-)

   - have you at least tried other kernels before claiming they are much
 larger ? Following your principle, 3.2 should be smaller and 3.16 not
 much larger. The former offers you about 6 extra months of maintenance,
 the latter 3.5 years (https://www.kernel.org/category/releases.html).


i also used 3.2 before. sure

dont get me wrong i work with all kernels, also with latests. i do also 
not complain that 3.10 is now EOL


i just wanted to throw some stones on the bloated kernel problem which 
is increasing





but even then the kernel is turning into a ram and space eating monster if i
look on devices with 16 mb ram and 4 mb flash. this is mainly for
maintaining older hardware with latest updates.

So why didn't you ask if it was possible to pursue the maintenance a bit a
long time ago ? LTS maintenance is a collective effort and is done based on
usage. If enough people have good reasons for going further it can be enough
a justification to push the deadline. Now it's too late.


didnt know that. the LTS deadline was defined a long time ago. i follow 
up the mailing lists mainly for reviewing patches


and reporting feedback if required. if it see such a discussion i may 
get in touch with it too, but with hundrets of emails every days here 
its hard to follow anything



the more recent hardware is getting better here

you dont seem to know how it is to work on wireless routers :-)

Yes I do, I've been distributing a full blown load balancer distro on a
10 MB image (running on 3.10 as well). But I also know that sometimes
you make some nice space savings on new kernels (xz/zstd compression,
ability to remove certain useless stuff in these environments such as
FS ACLs or mandatory locks, etc). Sure, upgrading to a new kernel on
existing hardware is always a challenge. But it's also an interesting
one.


i do use xz and i do use a modified squashfs which is even smaller than 
the xz one in the kernel


smallest router i run with linux has 8 mb ram and 2 mb flash. so i do 
know how to get all very small. 10 mb image is no issue for me. the 4 mb 
flashes devices are my problem.





Also just to give you an idea, I've just compared the size of these
kernels configured with "make allnoconfig" (and I verified that all
of them were compressed using gzip) :

   3.10.108 : 875 kB
   4.4.97   : 522 kB
   4.9.61   : 561 kB
   4.14 : 566 kB


its a little bit unrealistic since you have to count in network 
subsystem, filesystem and drivers.


standard kernel with xz compression is about 800 - 900 kb for me in 3.10 
and 4.4 / 4.9 etc. is often more than 1 - 1.2 mb


sometimes just the 100 kb more count in and turn into a problem since i 
have to remove something from the image to get it fitting


if you are really interested i can give you a real comparisation using a 
comparable config on 3.10, 4.4 and 4.9 for a standard mips target




So the argument that migrating away from 3.10 is hard due to the size
doesn't stand much here :-)
its turning harder. i already ported 4.4 and 4.9 as i said. so i tried 
already if they are running or not. they do run, but they are bigger and 
do not fit for some targets


Willy



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 3.10.108 (EOL)

[Sebastian Gottschall]

Am 14.11.2017 um 23:18 schrieb Willy Tarreau:

On Tue, Nov 14, 2017 at 11:00:46PM +0100, Sebastian Gottschall wrote:

Am 05.11.2017 um 08:46 schrieb Willy Tarreau:

On Sun, Nov 05, 2017 at 06:59:48AM +, Harsh Shandilya wrote:

Is this not pushed yet? I only see 3.10.107

Now it is there. Please avoid to rely on it for too long and quickly
upgrade to 4.4 or any other maintained version that suits your needs.

Willy


even if EOL has to come once for sure, its the last kernel which can be used
on certain devices (embedded) since the kernel is growing bigger and bigger
and wont run good anymore with limited resource

It's not totally true, each new kernel also provides options to disable
certain parts that are not used by everyone (syscalls, subsystems, etc).

And anyway the end of life has been indicated on kernel.org for 18 months
and in every announce in 2017, so it cannot be a surprize anymore :-) At
least nobody seemed to complain for all this time!


itsn no surprise for sure, but that also means i have to stay on the old 
kernel for these special devices and your argument about disable certain 
parts which simply turned bigger over time is no option


since it would remove features which existed before. its not that i 
enable all features of the kernel. i use every kernel with the same 
options (some are adjusted since they are renamed or moved)


but even then the kernel is turning into a ram and space eating monster 
if i look on devices with 16 mb ram and 4 mb flash. this is mainly for 
maintaining older hardware with latest updates. the more recent hardware 
is getting better here


you dont seem to know how it is to work on wireless routers :-)



Cheers,
Willy



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 3.10.108 (EOL)

[Sebastian Gottschall]

Am 14.11.2017 um 23:18 schrieb Willy Tarreau:

On Tue, Nov 14, 2017 at 11:00:46PM +0100, Sebastian Gottschall wrote:

Am 05.11.2017 um 08:46 schrieb Willy Tarreau:

On Sun, Nov 05, 2017 at 06:59:48AM +, Harsh Shandilya wrote:

Is this not pushed yet? I only see 3.10.107

Now it is there. Please avoid to rely on it for too long and quickly
upgrade to 4.4 or any other maintained version that suits your needs.

Willy


even if EOL has to come once for sure, its the last kernel which can be used
on certain devices (embedded) since the kernel is growing bigger and bigger
and wont run good anymore with limited resource

It's not totally true, each new kernel also provides options to disable
certain parts that are not used by everyone (syscalls, subsystems, etc).

And anyway the end of life has been indicated on kernel.org for 18 months
and in every announce in 2017, so it cannot be a surprize anymore :-) At
least nobody seemed to complain for all this time!


itsn no surprise for sure, but that also means i have to stay on the old 
kernel for these special devices and your argument about disable certain 
parts which simply turned bigger over time is no option


since it would remove features which existed before. its not that i 
enable all features of the kernel. i use every kernel with the same 
options (some are adjusted since they are renamed or moved)


but even then the kernel is turning into a ram and space eating monster 
if i look on devices with 16 mb ram and 4 mb flash. this is mainly for 
maintaining older hardware with latest updates. the more recent hardware 
is getting better here


you dont seem to know how it is to work on wireless routers :-)



Cheers,
Willy



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 3.10.108 (EOL)

[Sebastian Gottschall]

Am 05.11.2017 um 08:46 schrieb Willy Tarreau:

On Sun, Nov 05, 2017 at 06:59:48AM +, Harsh Shandilya wrote:

Is this not pushed yet? I only see 3.10.107

Now it is there. Please avoid to rely on it for too long and quickly
upgrade to 4.4 or any other maintained version that suits your needs.

Willy

even if EOL has to come once for sure, its the last kernel which can be 
used on certain devices (embedded) since the kernel is growing bigger 
and bigger and wont run good anymore with limited resource



Sebastian

--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Linux 3.10.108 (EOL)

[Sebastian Gottschall]

Am 05.11.2017 um 08:46 schrieb Willy Tarreau:

On Sun, Nov 05, 2017 at 06:59:48AM +, Harsh Shandilya wrote:

Is this not pushed yet? I only see 3.10.107

Now it is there. Please avoid to rely on it for too long and quickly
upgrade to 4.4 or any other maintained version that suits your needs.

Willy

even if EOL has to come once for sure, its the last kernel which can be 
used on certain devices (embedded) since the kernel is growing bigger 
and bigger and wont run good anymore with limited resource



Sebastian

--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

[Sebastian Gottschall]

Am 14.11.2017 um 08:41 schrieb Greg Kroah-Hartman:

On Tue, Nov 14, 2017 at 07:48:47AM +0100, Sebastian Gottschall wrote:

ahm it compiles well. but

[   24.838120] Unable to handle kernel NULL pointer dereference at virtual
address 0055
[   24.846193] pgd = c0004000
[   24.848893] [0055] *pgd=
[   24.852472] Internal error: Oops - BUG: 817 [#1] PREEMPT SMP ARM
[   24.858463] Modules linked in: xhci_plat_hcd xhci_pci xhci_hcd ohci_hcd
ehci_pci ehci_platform ehci_hcd usbcore usb_common nls_base qca_ssdk
gpio_pca953x mii_gpio wil6210 ath10k_pci ath10k_core ath9k ath9k_common
ath9k_hw ath mac80211 cfg80211 compat
[   24.880852] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.62-rc1 #90
[   24.887189] Hardware name: AnnapurnaLabs Alpine (Device Tree)
[   24.892921] task: ef029ac0 task.stack: ef05a000
[   24.897444] PC is at nf_nat_cleanup_conntrack+0x4c/0x74
[   24.902657] LR is at nf_nat_cleanup_conntrack+0x38/0x74
[   24.907869] pc : []    lr : []    psr: 6153
[   24.907869] sp : ef05bb58  ip : ef05bb58  fp : ef05bb6c
[   24.919317] r10: ed230cc0  r9 : ed230c00  r8 : edf45800
[   24.924529] r7 : ebcd2f00  r6 : ec33739e  r5 : c0892294  r4 : ebcd2f00
[   24.931040] r3 :   r2 : 0055  r1 :   r0 : c0892718
[   24.937551] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment
user
[   24.944755] Control: 10c5387d  Table: 2bd1006a  DAC: 0055
[   24.950486] Process swapper/2 (pid: 0, stack limit = 0xef05a210)
[   24.956477] Stack: (0xef05bb58 to 0xef05c000)


will dig into the code to find the reason

Can you run 'git bisect' or if you use quilt, do a manual bisect to find
the offending patch?


already done

netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to 
rhashtable"


this one caused the crash. if i revert it, its working again


Sebastian


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

[Sebastian Gottschall]

Am 14.11.2017 um 08:41 schrieb Greg Kroah-Hartman:

On Tue, Nov 14, 2017 at 07:48:47AM +0100, Sebastian Gottschall wrote:

ahm it compiles well. but

[   24.838120] Unable to handle kernel NULL pointer dereference at virtual
address 0055
[   24.846193] pgd = c0004000
[   24.848893] [0055] *pgd=
[   24.852472] Internal error: Oops - BUG: 817 [#1] PREEMPT SMP ARM
[   24.858463] Modules linked in: xhci_plat_hcd xhci_pci xhci_hcd ohci_hcd
ehci_pci ehci_platform ehci_hcd usbcore usb_common nls_base qca_ssdk
gpio_pca953x mii_gpio wil6210 ath10k_pci ath10k_core ath9k ath9k_common
ath9k_hw ath mac80211 cfg80211 compat
[   24.880852] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.62-rc1 #90
[   24.887189] Hardware name: AnnapurnaLabs Alpine (Device Tree)
[   24.892921] task: ef029ac0 task.stack: ef05a000
[   24.897444] PC is at nf_nat_cleanup_conntrack+0x4c/0x74
[   24.902657] LR is at nf_nat_cleanup_conntrack+0x38/0x74
[   24.907869] pc : []    lr : []    psr: 6153
[   24.907869] sp : ef05bb58  ip : ef05bb58  fp : ef05bb6c
[   24.919317] r10: ed230cc0  r9 : ed230c00  r8 : edf45800
[   24.924529] r7 : ebcd2f00  r6 : ec33739e  r5 : c0892294  r4 : ebcd2f00
[   24.931040] r3 :   r2 : 0055  r1 :   r0 : c0892718
[   24.937551] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment
user
[   24.944755] Control: 10c5387d  Table: 2bd1006a  DAC: 0055
[   24.950486] Process swapper/2 (pid: 0, stack limit = 0xef05a210)
[   24.956477] Stack: (0xef05bb58 to 0xef05c000)


will dig into the code to find the reason

Can you run 'git bisect' or if you use quilt, do a manual bisect to find
the offending patch?


already done

netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to 
rhashtable"


this one caused the crash. if i revert it, its working again


Sebastian


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

[Sebastian Gottschall]

|   3 +
  drivers/misc/cxl/pci.c |   3 +
  drivers/net/can/c_can/c_can_pci.c  |   1 -
  drivers/net/can/c_can/c_can_platform.c |   1 -
  drivers/net/can/ifi_canfd/ifi_canfd.c  |   6 +-
  drivers/net/can/sun4i_can.c|  12 +-
  drivers/net/usb/cdc_ncm.c  |  28 +
  drivers/net/usb/huawei_cdc_ncm.c   |   6 +
  drivers/net/wireless/ath/wcn36xx/main.c|   3 +-
  .../broadcom/brcm80211/brcmfmac/cfg80211.c |   9 +-
  drivers/net/wireless/marvell/libertas/cmd.c|   2 +-
  drivers/net/wireless/ralink/rt2x00/rt2800usb.c |   5 +-
  drivers/net/xen-netback/netback.c  |   6 +-
  drivers/pci/host/pci-mvebu.c   | 101 +---
  drivers/pinctrl/intel/pinctrl-baytrail.c   |   2 +-
  drivers/platform/x86/hp-wmi.c  |  60 ++
  drivers/s390/net/qeth_core.h   |   1 -
  drivers/s390/net/qeth_core_main.c  |  21 +++-
  drivers/s390/net/qeth_l2_main.c|  15 ---
  drivers/s390/net/qeth_l3_main.c|  15 ---
  drivers/s390/net/qeth_l3_sys.c |  30 ++---
  drivers/staging/iio/trigger/iio-trig-bfin-timer.c  |   4 +-
  drivers/tty/serial/sh-sci.c|  17 ++-
  drivers/usb/core/hcd.c |   1 +
  drivers/video/fbdev/pmag-ba-fb.c   |   2 +-
  include/dt-bindings/clock/exynos5433.h |   5 +-
  include/linux/phy.h|   8 +-
  include/linux/preempt.h|  21 ++--
  include/linux/usb/cdc_ncm.h|   1 +
  include/net/netfilter/nf_conntrack.h   |   3 +-
  include/net/netfilter/nf_nat.h |   1 -
  include/sound/seq_kernel.h |   3 +-
  kernel/sched/core.c|   1 +
  kernel/workqueue_internal.h|   3 +-
  lib/asn1_decoder.c |   4 +-
  net/dsa/Kconfig|   5 +-
  net/ipv4/ah4.c |   3 +
  net/netfilter/nf_nat_core.c| 133 +
  net/netfilter/nft_meta.c   |  28 -
  security/apparmor/lsm.c|   2 +-
  security/keys/trusted.c|  71 +--
  sound/core/seq/oss/seq_oss_midi.c  |   4 +-
  sound/core/seq/oss/seq_oss_readq.c |  29 +
  sound/core/seq/oss/seq_oss_readq.h |   2 +
  sound/soc/sunxi/sun4i-spdif.c  |   8 --
  tools/testing/selftests/firmware/fw_filesystem.sh  |   6 +-
  tools/testing/selftests/firmware/fw_userhelper.sh  |  28 -
  100 files changed, 722 insertions(+), 493 deletions(-)





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

[Sebastian Gottschall]

adq.c |  29 +
  sound/core/seq/oss/seq_oss_readq.h |   2 +
  sound/soc/sunxi/sun4i-spdif.c  |   8 --
  tools/testing/selftests/firmware/fw_filesystem.sh  |   6 +-
  tools/testing/selftests/firmware/fw_userhelper.sh  |  28 -
  100 files changed, 722 insertions(+), 493 deletions(-)





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill

[Sebastian Gottschall]

what about 4.9?

Am 06.11.2017 um 10:44 schrieb Greg Kroah-Hartman:

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Yan Markman <ymark...@marvell.com>

commit cda80a82ac3e89309706c027ada6ab232be1d640 upstream.

Under heavy system stress mvebu SoC using Cortex A9 sporadically
encountered instability issues.

The "double linefill" feature of L2 cache was identified as causing
dependency between read and write which lead to the deadlock.

Especially, it was the cause of deadlock seen under heavy PCIe traffic,
as this dependency violates PCIE overtaking rule.

Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 
configuration")
Signed-off-by: Yan Markman <ymark...@marvell.com>
Signed-off-by: Igal Liberman <ig...@marvell.com>
Signed-off-by: Nadav Haklai <nad...@marvell.com>
[gregory.clem...@free-electrons.com: reformulate commit log, add Armada
375 and add Fixes tag]
Signed-off-by: Gregory CLEMENT <gregory.clem...@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
  arch/arm/boot/dts/armada-375.dtsi |4 ++--
  arch/arm/boot/dts/armada-38x.dtsi |4 ++--
  arch/arm/boot/dts/armada-39x.dtsi |4 ++--
  3 files changed, 6 insertions(+), 6 deletions(-)

--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -176,9 +176,9 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
-   arm,double-linefill-incr = <1>;
+   arm,double-linefill-incr = <0>;
arm,double-linefill-wrap = <0>;
-   arm,double-linefill = <1>;
+   arm,double-linefill = <0>;
prefetch-data = <1>;
};
  
--- a/arch/arm/boot/dts/armada-38x.dtsi

+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -143,9 +143,9 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
-   arm,double-linefill-incr = <1>;
+   arm,double-linefill-incr = <0>;
arm,double-linefill-wrap = <0>;
-   arm,double-linefill = <1>;
+   arm,double-linefill = <0>;
prefetch-data = <1>;
};
  
--- a/arch/arm/boot/dts/armada-39x.dtsi

+++ b/arch/arm/boot/dts/armada-39x.dtsi
@@ -104,9 +104,9 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
-   arm,double-linefill-incr = <1>;
+   arm,double-linefill-incr = <0>;
arm,double-linefill-wrap = <0>;
-   arm,double-linefill = <1>;
+       arm,double-linefill = <0>;
prefetch-data = <1>;
};
  






--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill

[Sebastian Gottschall]

what about 4.9?

Am 06.11.2017 um 10:44 schrieb Greg Kroah-Hartman:

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Yan Markman 

commit cda80a82ac3e89309706c027ada6ab232be1d640 upstream.

Under heavy system stress mvebu SoC using Cortex A9 sporadically
encountered instability issues.

The "double linefill" feature of L2 cache was identified as causing
dependency between read and write which lead to the deadlock.

Especially, it was the cause of deadlock seen under heavy PCIe traffic,
as this dependency violates PCIE overtaking rule.

Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 
configuration")
Signed-off-by: Yan Markman 
Signed-off-by: Igal Liberman 
Signed-off-by: Nadav Haklai 
[gregory.clem...@free-electrons.com: reformulate commit log, add Armada
375 and add Fixes tag]
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman 

---
  arch/arm/boot/dts/armada-375.dtsi |4 ++--
  arch/arm/boot/dts/armada-38x.dtsi |4 ++--
  arch/arm/boot/dts/armada-39x.dtsi |4 ++--
  3 files changed, 6 insertions(+), 6 deletions(-)

--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -176,9 +176,9 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
-   arm,double-linefill-incr = <1>;
+   arm,double-linefill-incr = <0>;
arm,double-linefill-wrap = <0>;
-   arm,double-linefill = <1>;
+   arm,double-linefill = <0>;
prefetch-data = <1>;
};
  
--- a/arch/arm/boot/dts/armada-38x.dtsi

+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -143,9 +143,9 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
-   arm,double-linefill-incr = <1>;
+   arm,double-linefill-incr = <0>;
arm,double-linefill-wrap = <0>;
-   arm,double-linefill = <1>;
+   arm,double-linefill = <0>;
prefetch-data = <1>;
};
  
--- a/arch/arm/boot/dts/armada-39x.dtsi

+++ b/arch/arm/boot/dts/armada-39x.dtsi
@@ -104,9 +104,9 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
-   arm,double-linefill-incr = <1>;
+   arm,double-linefill-incr = <0>;
arm,double-linefill-wrap = <0>;
-   arm,double-linefill = <1>;
+   arm,double-linefill = <0>;
prefetch-data = <1>;
};
  






--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: hung task in mac80211

[Sebastian Gottschall]

 start_seq_num, ba_policy, tid,
+buf_size, tx, auto_seq);
+   mutex_unlock(>ampdu_mlme.mtx);
+}
+
  void ieee80211_process_addba_request(struct ieee80211_local *local,
  struct sta_info *sta,
  struct ieee80211_mgmt *mgmt,
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index c92df492e898..198b2d3e56fd 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -333,9 +333,9 @@ void ieee80211_ba_session_work(struct work_struct *work)

 if (test_and_clear_bit(tid,
sta->ampdu_mlme.tid_rx_manage_offl))
-   __ieee80211_start_rx_ba_session(sta, 0, 0, 0, 1, tid,
-   IEEE80211_MAX_AMPDU_BUF,
-   false, true);
+   ___ieee80211_start_rx_ba_session(sta, 0, 0, 0, 1, tid,
+
IEEE80211_MAX_AMPDU_BUF,
+false, true);

 if (test_and_clear_bit(tid + IEEE80211_NUM_TIDS,
sta->ampdu_mlme.tid_rx_manage_offl))
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 2197c62a0a6e..9675814f64db 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1760,6 +1760,10 @@ void __ieee80211_start_rx_ba_session(struct sta_info 
*sta,
  u8 dialog_token, u16 timeout,
  u16 start_seq_num, u16 ba_policy, u16 tid,
  u16 buf_size, bool tx, bool auto_seq);
+void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
+ u8 dialog_token, u16 timeout,
+ u16 start_seq_num, u16 ba_policy, u16 tid,
+ u16 buf_size, bool tx, bool auto_seq);
  void ieee80211_sta_tear_down_BA_sessions(struct sta_info *sta,
  enum ieee80211_agg_stop_reason 
reason);
  void ieee80211_process_delba(struct ieee80211_sub_if_data *sdata,

johannes

I confirm that this patch fixes the hang too.
I'm curious to see if there are noticeable performance differences
between the two solutions.

Cheers,



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: hung task in mac80211

[Sebastian Gottschall]

+buf_size, tx, auto_seq);
+   mutex_unlock(>ampdu_mlme.mtx);
+}
+
  void ieee80211_process_addba_request(struct ieee80211_local *local,
  struct sta_info *sta,
  struct ieee80211_mgmt *mgmt,
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index c92df492e898..198b2d3e56fd 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -333,9 +333,9 @@ void ieee80211_ba_session_work(struct work_struct *work)

 if (test_and_clear_bit(tid,
sta->ampdu_mlme.tid_rx_manage_offl))
-   __ieee80211_start_rx_ba_session(sta, 0, 0, 0, 1, tid,
-   IEEE80211_MAX_AMPDU_BUF,
-   false, true);
+   ___ieee80211_start_rx_ba_session(sta, 0, 0, 0, 1, tid,
+
IEEE80211_MAX_AMPDU_BUF,
+false, true);

 if (test_and_clear_bit(tid + IEEE80211_NUM_TIDS,
sta->ampdu_mlme.tid_rx_manage_offl))
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 2197c62a0a6e..9675814f64db 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1760,6 +1760,10 @@ void __ieee80211_start_rx_ba_session(struct sta_info 
*sta,
  u8 dialog_token, u16 timeout,
  u16 start_seq_num, u16 ba_policy, u16 tid,
  u16 buf_size, bool tx, bool auto_seq);
+void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
+ u8 dialog_token, u16 timeout,
+ u16 start_seq_num, u16 ba_policy, u16 tid,
+ u16 buf_size, bool tx, bool auto_seq);
  void ieee80211_sta_tear_down_BA_sessions(struct sta_info *sta,
  enum ieee80211_agg_stop_reason 
reason);
  void ieee80211_process_delba(struct ieee80211_sub_if_data *sdata,

johannes

I confirm that this patch fixes the hang too.
I'm curious to see if there are noticeable performance differences
between the two solutions.

Cheers,



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: hung task in mac80211

[Sebastian Gottschall]

Am 06.09.2017 um 15:03 schrieb Johannes Berg:

On Wed, 2017-09-06 at 14:48 +0200, Johannes Berg wrote:

I'm surprised nobody saw this before - though perhaps Sebastian's
useless report is the same.

Oh, that's because this is only for the offloaded manager thing, and
that's only ath10k.

johannes

that explans the behaviour i have found with latest mac80211 and ath10k.


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: hung task in mac80211

[Sebastian Gottschall]

Am 06.09.2017 um 15:03 schrieb Johannes Berg:

On Wed, 2017-09-06 at 14:48 +0200, Johannes Berg wrote:

I'm surprised nobody saw this before - though perhaps Sebastian's
useless report is the same.

Oh, that's because this is only for the offloaded manager thing, and
that's only ath10k.

johannes

that explans the behaviour i have found with latest mac80211 and ath10k.


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 2/3] ath10k: use size_t for len variables

[Sebastian Gottschall]

e 
*file, char __user *user_buf,
  size_t count, loff_t *ppos)
  {
struct ath10k *ar = file->private_data;
-   int len = 0;
+   size_t len;
char buf[32];
  
-	len = scnprintf(buf, sizeof(buf) - len, "%d\n",

-   ar->ani_enabled);
+   len = scnprintf(buf, sizeof(buf), "%d\n", ar->ani_enabled);
  
  	return simple_read_from_buffer(user_buf, count, ppos, buf, len);

  }
@@ -1584,11 +1582,10 @@ static ssize_t ath10k_read_nf_cal_period(struct file 
*file,
 size_t count, loff_t *ppos)
  {
struct ath10k *ar = file->private_data;
-   unsigned int len;
+   size_t len;
char buf[32];
  
-	len = scnprintf(buf, sizeof(buf), "%d\n",

-   ar->debug.nf_cal_period);
+   len = scnprintf(buf, sizeof(buf), "%d\n", ar->debug.nf_cal_period);
  
  	return simple_read_from_buffer(user_buf, count, ppos, buf, len);

  }
@@ -1684,9 +1681,10 @@ void ath10k_debug_tpc_stats_process(struct ath10k *ar,
  }
  
  static void ath10k_tpc_stats_print(struct ath10k_tpc_stats *tpc_stats,

-  unsigned int j, char *buf, unsigned int *len)
+  unsigned int j, char *buf, size_t *len)
  {
-   unsigned int i, buf_len;
+   int i;
+   size_t buf_len;
static const char table_str[][5] = { "CDD",
 "STBC",
 "TXBF" };
@@ -1726,7 +1724,8 @@ static void ath10k_tpc_stats_fill(struct ath10k *ar,
  struct ath10k_tpc_stats *tpc_stats,
  char *buf)
  {
-   unsigned int len, j, buf_len;
+   int j;
+   size_t len, buf_len;
  
  	len = 0;

buf_len = ATH10K_TPC_CONFIG_BUF_SIZE;
@@ -1860,7 +1859,7 @@ static ssize_t ath10k_tpc_stats_read(struct file *file, 
char __user *user_buf,
 size_t count, loff_t *ppos)
  {
const char *buf = file->private_data;
-   unsigned int len = strlen(buf);
+   size_t len = strlen(buf);
  
  	return simple_read_from_buffer(user_buf, count, ppos, buf, len);

  }
@@ -2284,7 +2283,7 @@ static ssize_t ath10k_debug_fw_checksums_read(struct file 
*file,
  size_t count, loff_t *ppos)
  {
struct ath10k *ar = file->private_data;
-   unsigned int len = 0, buf_len = 4096;
+   size_t len = 0, buf_len = 4096;
ssize_t ret_cnt;
char *buf;
  
@@ -2500,7 +2499,7 @@ void ath10k_dbg_dump(struct ath10k *ar,

 const void *buf, size_t len)
  {
char linebuf[256];
-   unsigned int linebuflen;
+   size_t linebuflen;
const void *ptr;
  
  	if (ath10k_debug_mask & mask) {

diff --git a/drivers/net/wireless/ath/ath10k/spectral.c 
b/drivers/net/wireless/ath/ath10k/spectral.c
index 2ffc1fe..c061d69 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -278,7 +278,7 @@ static ssize_t read_file_spec_scan_ctl(struct file *file, 
char __user *user_buf,
  {
struct ath10k *ar = file->private_data;
char *mode = "";
-   unsigned int len;
+   size_t len;
enum ath10k_spectral_mode spectral_mode;
  
  	mutex_lock(>conf_mutex);

@@ -370,7 +370,7 @@ static ssize_t read_file_spectral_count(struct file *file,
  {
struct ath10k *ar = file->private_data;
char buf[32];
-   unsigned int len;
+   size_t len;
u8 spectral_count;
  
  	mutex_lock(>conf_mutex);

@@ -422,7 +422,8 @@ static ssize_t read_file_spectral_bins(struct file *file,
  {
struct ath10k *ar = file->private_data;
char buf[32];
-   unsigned int len, bins, fft_size, bin_scale;
+   unsigned int bins, fft_size, bin_scale;
+   size_t len;
  
  	mutex_lock(>conf_mutex);
  



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 2/3] ath10k: use size_t for len variables

[Sebastian Gottschall]

  size_t count, loff_t *ppos)
  {
struct ath10k *ar = file->private_data;
-   int len = 0;
+   size_t len;
char buf[32];
  
-	len = scnprintf(buf, sizeof(buf) - len, "%d\n",

-   ar->ani_enabled);
+   len = scnprintf(buf, sizeof(buf), "%d\n", ar->ani_enabled);
  
  	return simple_read_from_buffer(user_buf, count, ppos, buf, len);

  }
@@ -1584,11 +1582,10 @@ static ssize_t ath10k_read_nf_cal_period(struct file 
*file,
 size_t count, loff_t *ppos)
  {
struct ath10k *ar = file->private_data;
-   unsigned int len;
+   size_t len;
char buf[32];
  
-	len = scnprintf(buf, sizeof(buf), "%d\n",

-   ar->debug.nf_cal_period);
+   len = scnprintf(buf, sizeof(buf), "%d\n", ar->debug.nf_cal_period);
  
  	return simple_read_from_buffer(user_buf, count, ppos, buf, len);

  }
@@ -1684,9 +1681,10 @@ void ath10k_debug_tpc_stats_process(struct ath10k *ar,
  }
  
  static void ath10k_tpc_stats_print(struct ath10k_tpc_stats *tpc_stats,

-  unsigned int j, char *buf, unsigned int *len)
+  unsigned int j, char *buf, size_t *len)
  {
-   unsigned int i, buf_len;
+   int i;
+   size_t buf_len;
static const char table_str[][5] = { "CDD",
 "STBC",
 "TXBF" };
@@ -1726,7 +1724,8 @@ static void ath10k_tpc_stats_fill(struct ath10k *ar,
  struct ath10k_tpc_stats *tpc_stats,
  char *buf)
  {
-   unsigned int len, j, buf_len;
+   int j;
+   size_t len, buf_len;
  
  	len = 0;

buf_len = ATH10K_TPC_CONFIG_BUF_SIZE;
@@ -1860,7 +1859,7 @@ static ssize_t ath10k_tpc_stats_read(struct file *file, 
char __user *user_buf,
 size_t count, loff_t *ppos)
  {
const char *buf = file->private_data;
-   unsigned int len = strlen(buf);
+   size_t len = strlen(buf);
  
  	return simple_read_from_buffer(user_buf, count, ppos, buf, len);

  }
@@ -2284,7 +2283,7 @@ static ssize_t ath10k_debug_fw_checksums_read(struct file 
*file,
  size_t count, loff_t *ppos)
  {
struct ath10k *ar = file->private_data;
-   unsigned int len = 0, buf_len = 4096;
+   size_t len = 0, buf_len = 4096;
ssize_t ret_cnt;
char *buf;
  
@@ -2500,7 +2499,7 @@ void ath10k_dbg_dump(struct ath10k *ar,

 const void *buf, size_t len)
  {
char linebuf[256];
-   unsigned int linebuflen;
+   size_t linebuflen;
const void *ptr;
  
  	if (ath10k_debug_mask & mask) {

diff --git a/drivers/net/wireless/ath/ath10k/spectral.c 
b/drivers/net/wireless/ath/ath10k/spectral.c
index 2ffc1fe..c061d69 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -278,7 +278,7 @@ static ssize_t read_file_spec_scan_ctl(struct file *file, 
char __user *user_buf,
  {
struct ath10k *ar = file->private_data;
char *mode = "";
-   unsigned int len;
+   size_t len;
enum ath10k_spectral_mode spectral_mode;
  
  	mutex_lock(>conf_mutex);

@@ -370,7 +370,7 @@ static ssize_t read_file_spectral_count(struct file *file,
  {
struct ath10k *ar = file->private_data;
char buf[32];
-   unsigned int len;
+   size_t len;
u8 spectral_count;
  
  	mutex_lock(>conf_mutex);

@@ -422,7 +422,8 @@ static ssize_t read_file_spectral_bins(struct file *file,
  {
struct ath10k *ar = file->private_data;
    char buf[32];
-   unsigned int len, bins, fft_size, bin_scale;
+   unsigned int bins, fft_size, bin_scale;
+   size_t len;
  
  	mutex_lock(>conf_mutex);
  



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [Xen-devel] [linux-4.1 bisection] complet

[Sebastian Gottschall]

Am 21.07.2016 um 16:23 schrieb Michal Hocko:

On Thu 21-07-16 13:45:40, Ian Jackson wrote:

I see that linux-4.1.y is still at 5880876e9469 which has the serious
bug introduced by the backport c5ad33184354 "mm/swap.c: flush lru
pvecs on compound page arrival".

The analogous problem is also still affecting at least linux-3.18.y.

Is there some problem with reverting this patch in the stable
branches ?

Sasha has mentioned he queued up the follow up fix. I am not sure who is



the 3.18 maintainer but he should do the same.

I am slightly worried that Sasha's email is bouncing for several days
and I am not sure who is his backup. For the time being I would just
suggest doing a local revert or apply Steven's patch from
http://www.spinics.net/lists/stable/msg138760.html

i patched it it locally and it resolved the issue in 3.18


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [Xen-devel] [linux-4.1 bisection] complet

[Sebastian Gottschall]

Am 21.07.2016 um 16:23 schrieb Michal Hocko:

On Thu 21-07-16 13:45:40, Ian Jackson wrote:

I see that linux-4.1.y is still at 5880876e9469 which has the serious
bug introduced by the backport c5ad33184354 "mm/swap.c: flush lru
pvecs on compound page arrival".

The analogous problem is also still affecting at least linux-3.18.y.

Is there some problem with reverting this patch in the stable
branches ?

Sasha has mentioned he queued up the follow up fix. I am not sure who is



the 3.18 maintainer but he should do the same.

I am slightly worried that Sasha's email is bouncing for several days
and I am not sure who is his backup. For the time being I would just
suggest doing a local revert or apply Steven's patch from
http://www.spinics.net/lists/stable/msg138760.html

i patched it it locally and it resolved the issue in 3.18


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [Xen-devel] [linux-4.1 bisection] complet

[Sebastian Gottschall]

i have the same issue without xen. for me network traffic causes oom 
within seconds to 3 minutes on embedded systems.
but i dont know if this is the cause. i just can say that it was 
introduced with 3.18.37



 Am 18.07.2016 um 18:18 schrieb Konrad Rzeszutek Wilk:

On Mon, Jul 18, 2016 at 03:48:03PM +, Odzioba, Lukasz wrote:

On Monday, July 18, 2016 5:31 PM, Konrad Rzeszutek Wilk wrote:

We found that your patch in the automated Xen test-case ends up
OOMing the box when trying to install guests. This worked prior
to your patch.

See serial log:
http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log

Would it be OK to revert this patch from the stable trees?

I think it is ok to revert that, but the source of a problem may be somewhere 
else.
Is it the only problem with this patch, you see?

I believe so.


By stable trees do you mean just 4.1 or all stable trees?

We have only tested 3.18 and 4.1. It may be that other stable trees
are affected.

Thanks,
Lukas

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [Xen-devel] [linux-4.1 bisection] complet

[Sebastian Gottschall]

i have the same issue without xen. for me network traffic causes oom 
within seconds to 3 minutes on embedded systems.
but i dont know if this is the cause. i just can say that it was 
introduced with 3.18.37



 Am 18.07.2016 um 18:18 schrieb Konrad Rzeszutek Wilk:

On Mon, Jul 18, 2016 at 03:48:03PM +, Odzioba, Lukasz wrote:

On Monday, July 18, 2016 5:31 PM, Konrad Rzeszutek Wilk wrote:

We found that your patch in the automated Xen test-case ends up
OOMing the box when trying to install guests. This worked prior
to your patch.

See serial log:
http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log

Would it be OK to revert this patch from the stable trees?

I think it is ok to revert that, but the source of a problem may be somewhere 
else.
Is it the only problem with this patch, you see?

I believe so.


By stable trees do you mean just 4.1 or all stable trees?

We have only tested 3.18 and 4.1. It may be that other stable trees
are affected.

Thanks,
Lukas

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

arm: ARM_VIRT_EXT is not supported by all v7 platforms, so it should not be enabled by default

[Sebastian Gottschall]

introduced in kernel 3.9 CONFIG_ARM_VIRT_EXT is default for all V7 arm 
cpu's. this is wrong and breaks smp support on BCM4708 for example.
so keep it optional since no all v7 cpu's seem to support it. BCM4708 
for instance is a arm cortex-a9. please merge this into one of the next 
patches.



Index: arch/arm/mm/Kconfig
===
--- arch/arm/mm/Kconfig (revision 21211)
+++ arch/arm/mm/Kconfig (working copy)
@@ -640,8 +640,7 @@

 config ARM_VIRT_EXT
bool
-   depends on MMU
-   default y if CPU_V7
+   depends on MMU && CPU_V7
help
  Enable the kernel to make use of the ARM Virtualization
  Extensions to install hypervisors without run-time firmware


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

arm: ARM_VIRT_EXT is not supported by all v7 platforms, so it should not be enabled by default

[Sebastian Gottschall]

introduced in kernel 3.9 CONFIG_ARM_VIRT_EXT is default for all V7 arm 
cpu's. this is wrong and breaks smp support on BCM4708 for example.
so keep it optional since no all v7 cpu's seem to support it. BCM4708 
for instance is a arm cortex-a9. please merge this into one of the next 
patches.



Index: arch/arm/mm/Kconfig
===
--- arch/arm/mm/Kconfig (revision 21211)
+++ arch/arm/mm/Kconfig (working copy)
@@ -640,8 +640,7 @@

 config ARM_VIRT_EXT
bool
-   depends on MMU
-   default y if CPU_V7
+   depends on MMU  CPU_V7
help
  Enable the kernel to make use of the ARM Virtualization
  Extensions to install hypervisors without run-time firmware


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/