On Sat, Dec 16, 2017 at 6:15 AM, Theodore Ts'o wrote:
> On Fri, Dec 15, 2017 at 05:39:25PM +0900, Byungchul Park wrote:
>>
>> All locks should belong to one class if each path of acquisition
>> can be switchable each other within the class at any time.
>> Otherwise, they should belong to a differe
On 12/15/2017 09:48 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> below are a couple important one or two liners fixes for Linux 4.15:
>
>
> The following changes since commit fcf38cdf332a81b20a59e3ebaea81f6b316bbe0c:
>
> kyber: fix another domain token wait queue hang (2017-12-06 12:33:07 -070
On Fri, Dec 15, 2017 at 05:39:25PM +0900, Byungchul Park wrote:
>
> All locks should belong to one class if each path of acquisition
> can be switchable each other within the class at any time.
> Otherwise, they should belong to a different class.
OK, so let's go back to my case of a Network Bloc
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Sorry to let you confuse, WARN_ON means we catch log as following:
WARNING: CPU: 3 PID: 3486 at block/genhd.c:680 device_add_disk+0x3d9/0x460
I do not get this warning for any of the kernels I build, whether from
Linus' tree or Jos
Before e33a9bba85a8, delayacct_blkio_end was called after
context-switching into the task which completed I/O. This resulted in
double counting: the task would account a delay both waiting for I/O and
for time spent in the runqueue.
With e33a9bba85a8, delayacct_blkio_end is called by try_to_wake_u
On Fri, 2017-12-15 at 15:58 +0800, chenxiang (M) wrote:
> I tested v2 of this series based on Martin's for-4.16 SCSI tree which
> branch error handler issue "scsi: core: Ensure that the
> SCSI error handler gets woken up" is merged. And system is still hung
> after repeat my testcase.
Hello chen
On Fri, Dec 15, 2017 at 09:18:56 -0800,
Laura Abbott wrote:
You can see the trees Fedora produces at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
which includes the configs (you want to look at the ones withtout - debug)
Thanks. I found it a little while ago and am alr
On 12/15/2017 08:30 AM, Bruno Wolff III wrote:
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Yes, please help reproduce this issue include my debug patch. Reproduce means
we can see WARN_ON in device_add_disk caused by failure of bdi_register_owner.
I'm not sure why yet, but
Hi Jens,
below are a couple important one or two liners fixes for Linux 4.15:
The following changes since commit fcf38cdf332a81b20a59e3ebaea81f6b316bbe0c:
kyber: fix another domain token wait queue hang (2017-12-06 12:33:07 -0700)
are available in the git repository at:
git://git.infradea
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Yes, please help reproduce this issue include my debug patch. Reproduce means
we can see WARN_ON in device_add_disk caused by failure of bdi_register_owner.
I'm not sure why yet, but I'm only getting the warning message you want
w
On 12/15/2017 03:31 PM, Peter Zijlstra wrote:
> On Fri, Dec 15, 2017 at 10:12:50AM +0800, jianchao.wang wrote:
>>> That only makes it a little better:
>>>
>>> Task-A Worker
>>>
>>> write_seqcount_begin()
>>> blk_mq_rw_update_state(rq, IN_FLIGHT)
>>>
2017-12-15 19:10 GMT+08:00 Bruno Wolff III :
> On Fri, Dec 15, 2017 at 10:04:32 +0800,
> weiping zhang wrote:
>>
>> I just want to know WARN_ON WHAT in device_add_disk,
>> if bdi_register_owner return error code, it may fail at any step of
>> following:
>
>
> Was that output in the original boot
Hello, Peter.
On Thu, Dec 14, 2017 at 09:20:42PM +0100, Peter Zijlstra wrote:
> But now that I look at this again, TJ, why can't the below happen?
>
> write_seqlock_begin();
> blk_mq_rq_update_state(rq, IN_FLIGHT);
> blk_add_timer(rq);
>
> read_seqcount_begi
Hello, Bart.
On Thu, Dec 14, 2017 at 09:13:32PM +, Bart Van Assche wrote:
...
> however is called before a every use of a request. Sorry but I'm not
> enthusiast about the code in blk_rq_init() that reinitializes state
> information that should survive request reuse.
If it wasn't clear, me ne
On Fri, Dec 15, 2017 at 10:04:32 +0800,
weiping zhang wrote:
I just want to know WARN_ON WHAT in device_add_disk,
if bdi_register_owner return error code, it may fail at any step of following:
Was that output in the original boot log? I didn't see anything there
that had the string WARN_ON.
On Fri, Dec 15, 2017 at 3:24 PM, Theodore Ts'o wrote:
> seems that lock classification as a solution to cross-release false
> positives seems unlikely:
For this, let me explain more.
For example, either to use cross-release or to consider
wait_for_completion() in submit_bio_wait() manually u
在 2017/12/14 5:53, Bart Van Assche 写道:
On Wed, 2017-11-29 at 10:57 +0800, chenxiang (M) wrote:
I applied this v2 patchset to kernel 4.15-rc1, running fio on a SATA
disk, then disable the disk with sysfs interface
(echo 0 > /sys/class/sas_phy/phy-1:0:1/enable), and find system is hung.
But with v
17 matches
Mail list logo
