Re: [PATCH net-next 3/5] iwlegacy: avoid -Wempty-body warning

l format string checks. > > Signed-off-by: Arnd Bergmann Acked-by: Stanislaw Gruszka

Re: [PATCH] iwlegacy: Add missing check in il4965_commit_rxon

On Sun, Feb 28, 2021 at 08:25:22PM +0800, Dinghao Liu wrote: > There is one il_set_tx_power() call in this function without > return value check. Print error message and return error code > on failure just like the other il_set_tx_power() call. We have few calls for il_set_tx_power(), on some

Re: [PATCH] iwlegacy: 4965-mac: Simplify the calculation of variables

On Thu, Feb 18, 2021 at 03:20:14PM +0800, Jiapeng Chong wrote: > Fix the following coccicheck warnings: > > ./drivers/net/wireless/intel/iwlegacy/4965-mac.c:2596:54-56: WARNING !A > || A && B is equivalent to !A || B. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- >

Re: [PATCH] iwlegacy: 4965-mac: Simplify the calculation of variables

off-by: Jiapeng Chong Acked-by: Stanislaw Gruszka

Re: "KMSAN: uninit-value in rt2500usb_bbp_read" and "KMSAN: uninit-value in rt2500usb_probe_hw" should be duplicate crash reports

On Thu, Jan 21, 2021 at 04:47:37PM +0800, 慕冬亮 wrote: > ## Patch > > I propose to memset reg variable before invoking > rt2x00usb_vendor_req_buff_lock/rt2x00usb_vendor_request_buff. > >

Re: [PATCH] mm/filemap: add static for function __add_to_page_cache_locked

On Wed, Dec 09, 2020 at 03:08:26PM +, Matthew Wilcox wrote: > On Wed, Dec 09, 2020 at 03:46:28PM +0100, Stanislaw Gruszka wrote: > > At this point of release cycle we should probably go with revert, > > but I think the main problem is that BPF and ERROR_INJECTION u

Re: [PATCH] mm/filemap: add static for function __add_to_page_cache_locked

On Mon, Dec 07, 2020 at 05:12:52PM -0800, Alexei Starovoitov wrote: > > > > > > > >>> -noinline int __add_to_page_cache_locked(struct page *page, > > > > > > > >>> +static noinline int __add_to_page_cache_locked(struct page > > > > > > > >>> *page, > > > > > > > >>>

Re: [PATCH v2] rt2x00: save survey for every channel visited

On Mon, Nov 02, 2020 at 06:19:32PM +0200, Kalle Valo wrote: > Марков Михаил Александрович writes: > > > rt2800 only gives you survey for current channel. > > > > Survey-based ACS algorithms are failing to perform their job when working > > with rt2800. > > > > Make rt2800 save survey for every

Re: [PATCH v2] rt2x00: save survey for every channel visited

nd be able to give away > that information. > > There is a bug registered https://dev.archive.openwrt.org/ticket/19081 and > this patch solves the issue. > > Signed-off-by: Markov Mikhail > > --- > Changes are now aggregated in rt2800lib.c. Acked-by: Stanislaw Gruszka Thanks Stanislaw

Re: [PATCH] rt2x00: save survey for every channel visited

On Mon, Oct 19, 2020 at 07:06:47PM +, Марков Михаил Александрович wrote: > rt2800 only gives you survey for current channel. > .watchdog= rt2800_watchdog, > +.update_survey= rt2800_update_survey, Since this feature is rt2800 specific, I would do not add new generic

Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring

On Thu, Jul 25, 2019 at 04:09:26PM +0800, Jian-Hong Pan wrote: > Each skb as the element in RX ring was expected with sized buffer 8216 > (RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is > 16640 bytes for alignment after allocated, x86_64 for example. And, the rtw88 advertise

Re: [PATCH net-next] rt2800usb: Add new rt2800usb device PLANEX GW-USMicroN

oN > > Signed-off-by: Masanari Iida Acked-by: Stanislaw Gruszka

Re: [PATCH] sched/cputime: make scale_stime() more precise

On Mon, Jul 22, 2019 at 10:00:34PM +0200, Peter Zijlstra wrote: > On Mon, Jul 22, 2019 at 12:52:41PM +0200, Stanislaw Gruszka wrote: > > On Fri, Jul 19, 2019 at 01:03:49PM +0200, Peter Zijlstra wrote: > > > > shows the problem even when sum_exec_runtime is not that big:

Re: [PATCH] sched/cputime: make scale_stime() more precise

On Fri, Jul 19, 2019 at 01:03:49PM +0200, Peter Zijlstra wrote: > > shows the problem even when sum_exec_runtime is not that big: 30 secs. > > > > The new implementation of scale_stime() does the additional div64_u64_rem() > > in a loop but see the comment, as long it is used by

Re: [PATCH] mac80211: don't warn about CW params when not using them

On Wed, Jul 17, 2019 at 06:57:12PM -0700, Brian Norris wrote: > ieee80211_set_wmm_default() normally sets up the initial CW min/max for > each queue, except that it skips doing this if the driver doesn't > support ->conf_tx. We still end up calling drv_conf_tx() in some cases > (e.g.,

Re: [PATCH v2 2/2] rt2x00usb: remove unnecessary rx flag checks

unnecessary ENTRY_DATA_STATUS_PENDING flag checks from the RX path. > Also remove the misleading comment about reading RX status from device. > > Suggested-by: Stanislaw Gruszka > Signed-off-by: Soeren Moch Acked-by: Stanislaw Gruszka

Re: [PATCH v2 1/2] rt2x00usb: fix rx queue hang

lush_queue: Warning - Queue 14 failed to flush". > Other operation modes are probably affected as well, this just was > the used testcase. > > Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete() > handler") > Cc: sta...@vger.kernel.org # 4.20+ > Signed-off-by: Soeren Moch Acked-by: Stanislaw Gruszka

Re: [PATCH] rt2x00: fix rx queue hang

On Mon, Jul 01, 2019 at 12:49:50PM +0200, Soeren Moch wrote: > Hello! > > On 29.06.19 10:50, Stanislaw Gruszka wrote: > > Hello > > > > On Wed, Jun 26, 2019 at 03:28:00PM +0200, Soeren Moch wrote: > >> Hi Stanislaw, > >> > >> the good

Re: [PATCH] rt2x00: fix rx queue hang

Hello On Wed, Jun 26, 2019 at 03:28:00PM +0200, Soeren Moch wrote: > Hi Stanislaw, > > the good news is: your patch below also solves the issue for me. But > removing the ENTRY_DATA_STATUS_PENDING check in > rt2x00usb_kick_rx_entry() alone does not help, while removing this check > in

Re: [PATCH] rt2x00: fix rx queue hang

Hello On Fri, Jun 21, 2019 at 01:30:01PM +0200, Soeren Moch wrote: > On 18.06.19 11:34, Stanislaw Gruszka wrote: > > Hi > > > > On Mon, Jun 17, 2019 at 11:46:56AM +0200, Soeren Moch wrote: > >> Since commit ed194d136769 ("usb: core: remove local_irq_save(

Re: [PATCH] rt2x00: fix rx queue hang

Hi On Mon, Jun 17, 2019 at 11:46:56AM +0200, Soeren Moch wrote: > Since commit ed194d136769 ("usb: core: remove local_irq_save() around > ->complete() handler") the handlers rt2x00usb_interrupt_rxdone() and > rt2x00usb_interrupt_txdone() are not running with interrupts disabled > anymore. So

Re: [PATCH] mt76: fix endianness sparse warnings

On Thu, Apr 25, 2019 at 10:42:01PM +0800, Ryder Lee wrote: > Fix many warnings with incorrect endian assumptions. > > Reported-by: kbuild test robot > Signed-off-by: Ryder Lee > --- > drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 2 +- > drivers/net/wireless/mediatek/mt76/mt7615/mac.c |

Re: MT76x2U crashes XHCI driver on AMD Ryzen system

On Thu, Feb 28, 2019 at 02:40:29PM +0100, Joerg Roedel wrote: > On Thu, Feb 28, 2019 at 01:19:48PM +0100, Stanislaw Gruszka wrote: > > Nevermind, the patch is wrong, s->dma_address is initalized in > > sg_num_pages(). > > Yes, it is. In sg_num_pages() the offse

Re: MT76x2U crashes XHCI driver on AMD Ryzen system

On Thu, Feb 28, 2019 at 11:42:24AM +0100, Stanislaw Gruszka wrote: > On Thu, Feb 28, 2019 at 10:04:12AM +0100, Stanislaw Gruszka wrote: > > On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote: > > > On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote: >

Re: MT76x2U crashes XHCI driver on AMD Ryzen system

On Thu, Feb 28, 2019 at 10:04:12AM +0100, Stanislaw Gruszka wrote: > On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote: > > On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote: > > > On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote: >

Re: MT76x2U crashes XHCI driver on AMD Ryzen system

On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote: > On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote: > > On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote: > > > On Tue, Feb 26, 2019 at 11:05:36AM +0100, Joerg Roedel wrote: &

Re: MT76x2U crashes XHCI driver on AMD Ryzen system

On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote: > On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote: > > On Tue, Feb 26, 2019 at 11:05:36AM +0100, Joerg Roedel wrote: > > If sg->offset > PAGE_SIZE is fine then most likely we have probl

Re: MT76x2U crashes XHCI driver on AMD Ryzen system

On Tue, Feb 26, 2019 at 11:05:36AM +0100, Joerg Roedel wrote: > On Mon, Feb 18, 2019 at 03:37:48PM +0100, Stanislaw Gruszka wrote: > > 0001-mt76x02u-use-usb_bulk_msg-to-upload-firmware.patch > > 0002-mt76usb-do-not-use-compound-head-page-for-SG-I-O.patch > > > > Or pr

Re: MT76x2U crashes XHCI driver on AMD Ryzen system

On Mon, Feb 18, 2019 at 05:01:59PM +, Robin Murphy wrote: > On 18/02/2019 14:37, Stanislaw Gruszka wrote: > [...] > >Another issue is that dma_map_sg() & dma_map_page() may require some > >constraints. I'm not sure about that and I want to clarify that with > >CCed

Re: MT76x2U crashes XHCI driver on AMD Ryzen system

(cc: IOMMU & page_frag_alloc maintainers) On Tue, Jan 15, 2019 at 10:04:01AM +0100, Lorenzo Bianconi wrote: > > On Mon, Jan 14, 2019 at 1:18 AM Lorenzo Bianconi > > wrote: > > > > > > > On Sun, Jan 13, 2019 at 11:00 AM Lorenzo Bianconi > > > > wrote: > > > > > > > > > > > > > > > > > > > > > >

Re: [PATCH] lib/div64: off by one in shift

On Mon, Jan 28, 2019 at 09:45:03AM -0800, Andrew Morton wrote: > On Mon, 28 Jan 2019 15:49:04 +0100 Stanislaw Gruszka > wrote: > > > fls counts bits starting from 1 to 32 (returns 0 for zero argument). > > If we add 1 we shift right one bit more and loose precision from &g

[PATCH] lib/div64: off by one in shift

=202391 Fixes: 658716d19f8f ("div64_u64(): improve precision on 32bit platforms") Reported-and-tested-by: Siarhei Volkau Signed-off-by: Stanislaw Gruszka --- lib/div64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/div64.c b/lib/div64.c index 01

Re: [PATCH] rt2x00: no need to check return value of debugfs_create functions

On Tue, Jan 22, 2019 at 04:21:34PM +0100, Greg Kroah-Hartman wrote: > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. > > Cc: Stanislaw Gruszk

Re: [PATCH] iwlegacy: no need to check return value of debugfs_create functions

On Tue, Jan 22, 2019 at 04:21:18PM +0100, Greg Kroah-Hartman wrote: > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. > > Cc: Stanislaw Grusz

Re: [PATCH] rt61pci: Work around a firmware bug with shared keys

firmware is > trying to be smarter than the driver, which is bound > to fail. > > As workaround the function rt61pci_config_shared_key > requests software decryption of the shared keys, > by returning EOPNOTSUPP. However, pairwise keys are > still handled by hardware which works just fine. > > Signed-off-by: Bernd Edlinger Acked-by: Stanislaw Gruszka

Re: [PATCH] net: wireless: iwlegacy: Fix possible data races in il4965_send_rxon_assoc()

On Thu, Oct 04, 2018 at 04:52:19PM +0800, Jia-Ju Bai wrote: > On 2018/10/4 15:59, Stanislaw Gruszka wrote: > >On Wed, Oct 03, 2018 at 10:07:45PM +0800, Jia-Ju Bai wrote: > >>These possible races are detected by a runtime testing. > >>To fix these ra

Re: [PATCH] net: wireless: iwlegacy: Fix possible data races in il4965_send_rxon_assoc()

On Thu, Oct 04, 2018 at 04:52:19PM +0800, Jia-Ju Bai wrote: > On 2018/10/4 15:59, Stanislaw Gruszka wrote: > >On Wed, Oct 03, 2018 at 10:07:45PM +0800, Jia-Ju Bai wrote: > >>These possible races are detected by a runtime testing. > >>To fix these ra

Re: [PATCH] rt2x00: fix spelling mistake in various macros, UKNOWN -> UNKNOWN

On Wed, Apr 18, 2018 at 12:47:50PM +0100, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com> > > Rename several macros that contain mispellings of UNKNOWN > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Acked-by: Stanislaw Gruszka <sgrus...@redhat.com>

Re: [PATCH] rt2x00: fix spelling mistake in various macros, UKNOWN -> UNKNOWN

On Wed, Apr 18, 2018 at 12:47:50PM +0100, Colin King wrote: > From: Colin Ian King > > Rename several macros that contain mispellings of UNKNOWN > > Signed-off-by: Colin Ian King Acked-by: Stanislaw Gruszka

Re: [PATCH] [linux-next] rt2x00: Fix a typo in printk

On Fri, Jan 05, 2018 at 12:08:00AM +0900, Masanari Iida wrote: > This patch fix a typo in rt2800lib.c > > Signed-off-by: Masanari Iida <standby2...@gmail.com> Acked-by: Stanislaw Gruszka <sgrus...@redhat.com>

Re: [PATCH] [linux-next] rt2x00: Fix a typo in printk

On Fri, Jan 05, 2018 at 12:08:00AM +0900, Masanari Iida wrote: > This patch fix a typo in rt2800lib.c > > Signed-off-by: Masanari Iida Acked-by: Stanislaw Gruszka

Re: [PATCH] rt2x00: Delete an error message for a failed memory allocation in rt2x00queue_allocate()

by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> Acked-by: Stanislaw Gruszka <sgrus...@redhat.com>

Re: [PATCH] rt2x00: Delete an error message for a failed memory allocation in rt2x00queue_allocate()

t; Signed-off-by: Markus Elfring Acked-by: Stanislaw Gruszka

Re: Soft lockup in rt2x00usb_work_rxdone()

On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote: > (maybe if there was more than one CPU on the board, I could do > something, but that's not the case) I reproduced the problem with nosmp option. I think we need to check also for ENOENT error (not only for ENODEV). Will post the

Re: Soft lockup in rt2x00usb_work_rxdone()

On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote: > (maybe if there was more than one CPU on the board, I could do > something, but that's not the case) I reproduced the problem with nosmp option. I think we need to check also for ENOENT error (not only for ENODEV). Will post the

Re: Soft lockup in rt2x00usb_work_rxdone()

On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote: > > No, that not I wanted you to do. Please remove those options and just > > do > > below on tracing directory. > > > > echo 0 > tracing_on  > > cat trace >  /dev/null > > echo "function_graph" > current_tracer  > > echo "rt2*" >

Re: Soft lockup in rt2x00usb_work_rxdone()

On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote: > > No, that not I wanted you to do. Please remove those options and just > > do > > below on tracing directory. > > > > echo 0 > tracing_on  > > cat trace >  /dev/null > > echo "function_graph" > current_tracer  > > echo "rt2*" >

Re: Soft lockup in rt2x00usb_work_rxdone()

On Tue, Nov 07, 2017 at 12:13:47PM +0100, Richard Genoud wrote: > Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit : > > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote: > > > > 3 short articles how to configure and use ftrace are here: &g

Re: Soft lockup in rt2x00usb_work_rxdone()

On Tue, Nov 07, 2017 at 12:13:47PM +0100, Richard Genoud wrote: > Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit : > > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote: > > > > 3 short articles how to configure and use ftrace are here: &g

Re: Soft lockup in rt2x00usb_work_rxdone()

On Tue, Nov 07, 2017 at 12:01:23PM +0100, Richard Genoud wrote: > Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit : > > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote: > > > > 3 short articles how to configure and use ftrace are here: &g

Re: Soft lockup in rt2x00usb_work_rxdone()

On Tue, Nov 07, 2017 at 12:01:23PM +0100, Richard Genoud wrote: > Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit : > > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote: > > > > 3 short articles how to configure and use ftrace are here: &g

Re: Soft lockup in rt2x00usb_work_rxdone()

On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote: > > 3 short articles how to configure and use ftrace are here: > > https://lwn.net/Articles/365835/ > > https://lwn.net/Articles/366796/ > > https://lwn.net/Articles/370423/ > > > I tried with ftrace, but I don't think there's a way

Re: Soft lockup in rt2x00usb_work_rxdone()

On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote: > > 3 short articles how to configure and use ftrace are here: > > https://lwn.net/Articles/365835/ > > https://lwn.net/Articles/366796/ > > https://lwn.net/Articles/370423/ > > > I tried with ftrace, but I don't think there's a way

Re: Soft lockup in rt2x00usb_work_rxdone()

Hi On Mon, Nov 06, 2017 at 04:57:09PM +0100, Richard Genoud wrote: > I get a soft lock-up while unbinding the USB driver on a TP-Link TL-WN727Nv3 > (chipset 5370): > > # echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind > watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:3:308] ... > I

Re: Soft lockup in rt2x00usb_work_rxdone()

Hi On Mon, Nov 06, 2017 at 04:57:09PM +0100, Richard Genoud wrote: > I get a soft lock-up while unbinding the USB driver on a TP-Link TL-WN727Nv3 > (chipset 5370): > > # echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind > watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:3:308] ... > I

Re: [PATCH] wireless: iwlegacy: Convert timers to use timer_setup()

On Mon, Oct 16, 2017 at 04:37:44PM -0700, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Stanislaw

Re: [PATCH] wireless: iwlegacy: Convert timers to use timer_setup()

On Mon, Oct 16, 2017 at 04:37:44PM -0700, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Stanislaw Grusz

Re: rc2-next-20170929: wireless down, won't come up

On Mon, Oct 16, 2017 at 02:24:56PM +0200, Pavel Machek wrote: > So far it happened once... so I don't know about reproducibility. And > I'm not even sure if I'm using iwlegacy driver. Am I? iwl3945 (and iwl4965) are iwlegacy drivers. Regards Stanislaw

Re: rc2-next-20170929: wireless down, won't come up

On Mon, Oct 16, 2017 at 02:24:56PM +0200, Pavel Machek wrote: > So far it happened once... so I don't know about reproducibility. And > I'm not even sure if I'm using iwlegacy driver. Am I? iwl3945 (and iwl4965) are iwlegacy drivers. Regards Stanislaw

Re: rc2-next-20170929: wireless down, won't come up

Hi Site note: Intel folks do not support iwlegacy, I removed them from CC. On Mon, Oct 16, 2017 at 12:27:45PM +0200, Pavel Machek wrote: > > In -next... after few days of usage with suspend and resume cycles, > > wifi failed on thinkpad x60. I have not seen this in years... > > Any ideas? We

Re: rc2-next-20170929: wireless down, won't come up

Hi Site note: Intel folks do not support iwlegacy, I removed them from CC. On Mon, Oct 16, 2017 at 12:27:45PM +0200, Pavel Machek wrote: > > In -next... after few days of usage with suspend and resume cycles, > > wifi failed on thinkpad x60. I have not seen this in years... > > Any ideas? We

Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index

Hi Dmitry On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote: > On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka <sgrus...@redhat.com> > wrote: > > Hi > > > > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote: > >> I've

Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index

Hi Dmitry On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote: > On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka > wrote: > > Hi > > > > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote: > >> I've got the following report while

Re: Crash in bm_evict_inode() during shutdown.

On Fri, Oct 13, 2017 at 04:47:45PM +0200, Oleg Nesterov wrote: > Yes, sorry, my fault. Fixed by the patch from Eryu, already in -mm tree. No worries, I just used power button to "help" the system to shutdown :-) Now is fixed in mainline, thanks. Stanislaw

Re: Crash in bm_evict_inode() during shutdown.

On Fri, Oct 13, 2017 at 04:47:45PM +0200, Oleg Nesterov wrote: > Yes, sorry, my fault. Fixed by the patch from Eryu, already in -mm tree. No worries, I just used power button to "help" the system to shutdown :-) Now is fixed in mainline, thanks. Stanislaw

Crash in bm_evict_inode() during shutdown.

On 4.14-rc4 updated today, I have OOPS on bm_evict_inode(). It happens every time during shutdown of the system. Seems e = inode->i_private is NULL and e->flags crashes. Picture with the OOPS call trace is here: http://people.redhat.com/sgruszka/DSC_0733.JPG Thanks Stanislaw

Crash in bm_evict_inode() during shutdown.

On 4.14-rc4 updated today, I have OOPS on bm_evict_inode(). It happens every time during shutdown of the system. Seems e = inode->i_private is NULL and e->flags crashes. Picture with the OOPS call trace is here: http://people.redhat.com/sgruszka/DSC_0733.JPG Thanks Stanislaw

Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index

Hi On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote: > I've got the following report while fuzzing the kernel with syzkaller. > > On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). > > I'm not sure whether this is a bug in the driver, or just a way to > report

Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index

Hi On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote: > I've got the following report while fuzzing the kernel with syzkaller. > > On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). > > I'm not sure whether this is a bug in the driver, or just a way to > report

Re: [PATCH 1/1] sched/cputime: do not decrease steal time after live migration on xen

On Tue, Oct 10, 2017 at 12:59:26PM +0200, Ingo Molnar wrote: > > (Cc:-ed more gents involved in kernel/sched/cputime.c work. Full patch quoted > below.) > > * Dongli Zhang wrote: > > > After guest live migration on xen, steal time in /proc/stat > >

Re: [PATCH 1/1] sched/cputime: do not decrease steal time after live migration on xen

On Tue, Oct 10, 2017 at 12:59:26PM +0200, Ingo Molnar wrote: > > (Cc:-ed more gents involved in kernel/sched/cputime.c work. Full patch quoted > below.) > > * Dongli Zhang wrote: > > > After guest live migration on xen, steal time in /proc/stat > > (cpustat[CPUTIME_STEAL]) might decrease

Re: [PATCH] wireless: iwlegacy: make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit

ed-off-by: Colin Ian King <colin.k...@canonical.com> Content type information was added at the end of the topic, but I think Kalle can fix that when he will be committing the patch. Acked-by: Stanislaw Gruszka <sgrus...@redhat.com>

Re: [PATCH] wireless: iwlegacy: make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit

Content type information was added at the end of the topic, but I think Kalle can fix that when he will be committing the patch. Acked-by: Stanislaw Gruszka

Re: [tip:sched/core] sched/cputime: Refactor the cputime_adjust() code

On Fri, Jun 30, 2017 at 06:10:35AM -0700, tip-bot for Gustavo A. R. Silva wrote: > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c > index aea3135..67c70e2 100644 > --- a/kernel/sched/cputime.c > +++ b/kernel/sched/cputime.c > @@ -615,19 +615,13 @@ static void cputime_adjust(struct

Re: [tip:sched/core] sched/cputime: Refactor the cputime_adjust() code

On Fri, Jun 30, 2017 at 06:10:35AM -0700, tip-bot for Gustavo A. R. Silva wrote: > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c > index aea3135..67c70e2 100644 > --- a/kernel/sched/cputime.c > +++ b/kernel/sched/cputime.c > @@ -615,19 +615,13 @@ static void cputime_adjust(struct

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 01:55:17PM +0200, Stanislaw Gruszka wrote: > On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: > > From: Stanislaw Gruszka <sgrus...@redhat.com> > > Date: Mon, 15 May 2017 16:28:01 +0200 > > > > > On Mon, May 15, 2017 at 0

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 01:55:17PM +0200, Stanislaw Gruszka wrote: > On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: > > From: Stanislaw Gruszka > > Date: Mon, 15 May 2017 16:28:01 +0200 > > > > > On Mon, May 15, 2017 at 03:46:5

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 01:58:56PM +0200, Johannes Berg wrote: > On Tue, 2017-05-16 at 13:55 +0200, Stanislaw Gruszka wrote: > > > > In rt2x00 driver we use poor convention in other kind of registers > > accessors like bbp, mac, eeprom. I dislike to changing only rfcsr >

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 01:58:56PM +0200, Johannes Berg wrote: > On Tue, 2017-05-16 at 13:55 +0200, Stanislaw Gruszka wrote: > > > > In rt2x00 driver we use poor convention in other kind of registers > > accessors like bbp, mac, eeprom. I dislike to changing only rfcsr >

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: > From: Stanislaw Gruszka <sgrus...@redhat.com> > Date: Mon, 15 May 2017 16:28:01 +0200 > > > On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote: > >> With CONFIG_KASAN enabled and gcc-7, we g

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: > From: Stanislaw Gruszka > Date: Mon, 15 May 2017 16:28:01 +0200 > > > On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote: > >> With CONFIG_KASAN enabled and gcc-7, we get a warning about rath

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote: > With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high > stack usage (with a private patch set I have to turn on this warning, > which I intend to get into the next kernel release): > >

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote: > With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high > stack usage (with a private patch set I have to turn on this warning, > which I intend to get into the next kernel release): > >

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

On Mon, Apr 24, 2017 at 10:06:32PM +0900, Tetsuo Handa wrote: > Stanislaw Gruszka wrote: > > On Sun, Apr 23, 2017 at 07:24:21PM +0900, Tetsuo Handa wrote: > > > On 2017/03/10 20:44, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > >> I am defin

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

On Mon, Apr 24, 2017 at 10:06:32PM +0900, Tetsuo Handa wrote: > Stanislaw Gruszka wrote: > > On Sun, Apr 23, 2017 at 07:24:21PM +0900, Tetsuo Handa wrote: > > > On 2017/03/10 20:44, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > >> I am defin

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

On Sun, Apr 23, 2017 at 07:24:21PM +0900, Tetsuo Handa wrote: > On 2017/03/10 20:44, Tetsuo Handa wrote: > > Michal Hocko wrote: > >> On Thu 09-03-17 13:05:40, Johannes Weiner wrote: > >>> On Tue, Mar 07, 2017 at 02:52:36PM -0500, Rik van Riel wrote: > It only does this to some extent. If

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

On Sun, Apr 23, 2017 at 07:24:21PM +0900, Tetsuo Handa wrote: > On 2017/03/10 20:44, Tetsuo Handa wrote: > > Michal Hocko wrote: > >> On Thu 09-03-17 13:05:40, Johannes Weiner wrote: > >>> On Tue, Mar 07, 2017 at 02:52:36PM -0500, Rik van Riel wrote: > It only does this to some extent. If

Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen

a NULL or we get a pointer to an inited structure. > > As for the hypervisor -- that falls back to more limited state after > resume (because some of this state is thrown away at suspend) and so > uses that until it gets the uploaded PM state from the initial-domain. Patch looks good

Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen

a NULL or we get a pointer to an inited structure. > > As for the hypervisor -- that falls back to more limited state after > resume (because some of this state is thrown away at suspend) and so > uses that until it gets the uploaded PM state from the initial-domain. Patch looks good to me then. Reviewed-by: Stanislaw Gruszka

Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen

On Tue, Mar 21, 2017 at 03:43:38PM -0700, Ankur Arora wrote: > This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4. > do_suspend (from xen/manage.c) and thus xen_resume_notifier never get > called on the initial-domain at resume (it is if running as guest.) > > The rationale for

Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen

On Tue, Mar 21, 2017 at 03:43:38PM -0700, Ankur Arora wrote: > This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4. > do_suspend (from xen/manage.c) and thus xen_resume_notifier never get > called on the initial-domain at resume (it is if running as guest.) > > The rationale for

Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs

On Mon, Jan 30, 2017 at 03:56:49PM +0100, Frederic Weisbecker wrote: > On Mon, Jan 30, 2017 at 03:32:24PM +0100, Stanislaw Gruszka wrote: > > On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote: > > > Now lets admit one drawback

Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs

On Mon, Jan 30, 2017 at 03:56:49PM +0100, Frederic Weisbecker wrote: > On Mon, Jan 30, 2017 at 03:32:24PM +0100, Stanislaw Gruszka wrote: > > On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote: > > > Now lets admit one drawback

Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs

On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote: > Now lets admit one drawback: s390 and powerpc with > CONFIG_VIRT_CPU_ACCOUNTING_NATIVE have new cputime_t to nsecs conversion > on cputime accounting path. But this should be leveraged by the recent > changes which delay the

Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs

On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote: > Now lets admit one drawback: s390 and powerpc with > CONFIG_VIRT_CPU_ACCOUNTING_NATIVE have new cputime_t to nsecs conversion > on cputime accounting path. But this should be leveraged by the recent > changes which delay the

Re: [PATCH 08/37] cputime: Convert task/group cputime to nsecs

On Sat, Jan 28, 2017 at 04:28:13PM +0100, Frederic Weisbecker wrote: > On Sat, Jan 28, 2017 at 12:57:40PM +0100, Stanislaw Gruszka wrote: > > On 32 bit architectures 64bit store/load is not atomic and if not > > protected - 64bit variables can be mangled. I do not see any prote

Re: [PATCH 08/37] cputime: Convert task/group cputime to nsecs

On Sat, Jan 28, 2017 at 04:28:13PM +0100, Frederic Weisbecker wrote: > On Sat, Jan 28, 2017 at 12:57:40PM +0100, Stanislaw Gruszka wrote: > > On 32 bit architectures 64bit store/load is not atomic and if not > > protected - 64bit variables can be mangled. I do not see any prote

Re: [PATCH 08/37] cputime: Convert task/group cputime to nsecs

Hi Frederic and sorry for late comment. On Sun, Jan 22, 2017 at 07:19:44PM +0100, Frederic Weisbecker wrote: > Now that most cputime readers use the transition API which return the > task cputime in old style cputime_t, we can safely store the cputime in > nsecs. This will eventually make cputime

Re: [PATCH 08/37] cputime: Convert task/group cputime to nsecs

Hi Frederic and sorry for late comment. On Sun, Jan 22, 2017 at 07:19:44PM +0100, Frederic Weisbecker wrote: > Now that most cputime readers use the transition API which return the > task cputime in old style cputime_t, we can safely store the cputime in > nsecs. This will eventually make cputime

[tip:sched/core] sched/cputime: Simplify task_cputime()

Commit-ID: 353c50ebe329daaf2c94dc41c1c481cbba2a31fd Gitweb: http://git.kernel.org/tip/353c50ebe329daaf2c94dc41c1c481cbba2a31fd Author: Stanislaw Gruszka <sgrus...@redhat.com> AuthorDate: Tue, 15 Nov 2016 03:06:52 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

  1   2   3   4   5   >