On Thu, Jul 09, 2020 at 11:59:09AM -0700, Cong Wang wrote:
> On Thu, Jul 9, 2020 at 11:51 AM Cong Wang wrote:
> >
> > On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote:
> > >
> > > Something seems fishy with the use of skcd->val on big endian systems.
> > >
> > > Some debug output:
> > >
> > >
On Thu, Jul 09, 2020 at 11:59:09AM -0700, Cong Wang wrote:
> On Thu, Jul 9, 2020 at 11:51 AM Cong Wang wrote:
> >
> > On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote:
> > >
> > > Something seems fishy with the use of skcd->val on big endian systems.
> > >
> > > Some debug output:
> > >
> > >
From: Cong Wang
Date: Thu, 9 Jul 2020 12:19:40 -0700
> Make sure you test the second patch I sent, not the first one. The
> first one is still incomplete and ugly too. The two bits must be the
> last two, so correcting the if test is not sufficient, we have to
> fix the whole bitfield packing.
T
On Thu, Jul 9, 2020 at 12:13 PM Guenter Roeck wrote:
>
> On 7/9/20 11:51 AM, Cong Wang wrote:
> > On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote:
> >>
> >> Something seems fishy with the use of skcd->val on big endian systems.
> >>
> >> Some debug output:
> >>
> >> [ 22.643703] sock: #
On 7/9/20 11:51 AM, Cong Wang wrote:
> On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote:
>>
>> Something seems fishy with the use of skcd->val on big endian systems.
>>
>> Some debug output:
>>
>> [ 22.643703] sock: # sk_alloc(sk=1be28100): Calling
>> cgroup_sk_alloc(1be2
On Thu, Jul 9, 2020 at 11:51 AM Cong Wang wrote:
>
> On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote:
> >
> > Something seems fishy with the use of skcd->val on big endian systems.
> >
> > Some debug output:
> >
> > [ 22.643703] sock: # sk_alloc(sk=1be28100): Calling
> > cgroup
On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote:
>
> Something seems fishy with the use of skcd->val on big endian systems.
>
> Some debug output:
>
> [ 22.643703] sock: # sk_alloc(sk=1be28100): Calling
> cgroup_sk_alloc(1be28550)
> [ 22.643807] cgroup: # cgroup_sk
On 7/8/20 12:32 PM, Cong Wang wrote:
> On Wed, Jul 8, 2020 at 12:07 PM Guenter Roeck wrote:
>>
>> On 7/8/20 11:34 AM, Cong Wang wrote:
>>> Hi,
>>>
>>> On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote:
This patch causes all my s390 boot tests to crash. Reverting it fixes
the problem. P
On 7/8/20 12:32 PM, Cong Wang wrote:
> On Wed, Jul 8, 2020 at 12:07 PM Guenter Roeck wrote:
>>
>> On 7/8/20 11:34 AM, Cong Wang wrote:
>>> Hi,
>>>
>>> On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote:
This patch causes all my s390 boot tests to crash. Reverting it fixes
the problem. P
On Wed, Jul 8, 2020 at 12:07 PM Guenter Roeck wrote:
>
> On 7/8/20 11:34 AM, Cong Wang wrote:
> > Hi,
> >
> > On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote:
> >> This patch causes all my s390 boot tests to crash. Reverting it fixes
> >> the problem. Please see bisect results and and crash lo
On 7/8/20 11:34 AM, Cong Wang wrote:
> Hi,
>
> On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote:
>> This patch causes all my s390 boot tests to crash. Reverting it fixes
>> the problem. Please see bisect results and and crash log below.
>>
> ...
>> Crash log:
>
> Interesting. I don't see how u
Hi,
On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote:
> This patch causes all my s390 boot tests to crash. Reverting it fixes
> the problem. Please see bisect results and and crash log below.
>
...
> Crash log:
Interesting. I don't see how unix socket is any special here, it creates
a peer soc
Hi,
On Thu, Jul 02, 2020 at 11:52:56AM -0700, Cong Wang wrote:
> When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
> copied, so the cgroup refcnt must be taken too. And, unlike the
> sk_alloc() path, sock_update_netprioidx() is not called here.
> Therefore, it is safe and necessary to
From: Cong Wang
Date: Thu, 2 Jul 2020 11:52:56 -0700
> When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
> copied, so the cgroup refcnt must be taken too. And, unlike the
> sk_alloc() path, sock_update_netprioidx() is not called here.
> Therefore, it is safe and necessary to grab th
When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
copied, so the cgroup refcnt must be taken too. And, unlike the
sk_alloc() path, sock_update_netprioidx() is not called here.
Therefore, it is safe and necessary to grab the cgroup refcnt
even when cgroup_sk_alloc is disabled.
sk_clone
15 matches
Mail list logo