On Fri, Jul 03, 2020 at 09:52:01AM +0900, Tetsuo Handa wrote:
> On 2020/07/03 4:46, Luis Chamberlain wrote:
> > The alternative to making a compromise is using generic wrappers for
> > things which make sense and letting the callers use those.
>
> I suggest just introducing
>
On 2020/07/03 4:46, Luis Chamberlain wrote:
> On Thu, Jul 02, 2020 at 01:26:53PM +0900, Tetsuo Handa wrote:
>> On 2020/07/02 0:38, Luis Chamberlain wrote:
>>> @@ -156,6 +156,18 @@ static void call_usermodehelper_exec_sync(struct
>>> subprocess_info *sub_info)
>>> */
>>>
On Thu, Jul 02, 2020 at 01:26:53PM +0900, Tetsuo Handa wrote:
> On 2020/07/02 0:38, Luis Chamberlain wrote:
> > @@ -156,6 +156,18 @@ static void call_usermodehelper_exec_sync(struct
> > subprocess_info *sub_info)
> > */
> > if (KWIFEXITED(ret))
> >
On 2020/07/02 0:38, Luis Chamberlain wrote:
> @@ -156,6 +156,18 @@ static void call_usermodehelper_exec_sync(struct
> subprocess_info *sub_info)
>*/
> if (KWIFEXITED(ret))
> sub_info->retval = KWEXITSTATUS(ret);
> + /*
> +
On 01.07.20 17:58, Luis Chamberlain wrote:
[...]
>>>
>>> Ah, well that would be a different fix required, becuase again,
>>> br_stp_start() does not untangle the correct error today really.
>>> I also I think it would be odd odd that SIGSEGV or another signal
>>> is what was terminating
On Wed, Jul 01, 2020 at 05:48:48PM +0200, Christian Borntraeger wrote:
>
>
> On 01.07.20 17:38, Luis Chamberlain wrote:
> > On Wed, Jul 01, 2020 at 11:08:57PM +0900, Tetsuo Handa wrote:
> >> On 2020/07/01 22:53, Luis Chamberlain wrote:
> Well, it is not br_stp_call_user() but br_stp_start()
On 01.07.20 17:38, Luis Chamberlain wrote:
> On Wed, Jul 01, 2020 at 11:08:57PM +0900, Tetsuo Handa wrote:
>> On 2020/07/01 22:53, Luis Chamberlain wrote:
Well, it is not br_stp_call_user() but br_stp_start() which is expecting
to set sub_info->retval for both KWIFEXITED() case and
On Wed, Jul 01, 2020 at 11:08:57PM +0900, Tetsuo Handa wrote:
> On 2020/07/01 22:53, Luis Chamberlain wrote:
> >> Well, it is not br_stp_call_user() but br_stp_start() which is expecting
> >> to set sub_info->retval for both KWIFEXITED() case and KWIFSIGNALED() case.
> >> That is, sub_info->retval
On 01.07.20 15:53, Luis Chamberlain wrote:
> On Wed, Jul 01, 2020 at 10:24:29PM +0900, Tetsuo Handa wrote:
>> On 2020/07/01 19:08, Christian Borntraeger wrote:
>>>
>>>
>>> On 30.06.20 19:57, Luis Chamberlain wrote:
On Fri, Jun 26, 2020 at 02:54:10AM +, Luis Chamberlain wrote:
> On
On 2020/07/01 22:53, Luis Chamberlain wrote:
>> Well, it is not br_stp_call_user() but br_stp_start() which is expecting
>> to set sub_info->retval for both KWIFEXITED() case and KWIFSIGNALED() case.
>> That is, sub_info->retval needs to carry raw value (i.e. without "umh: fix
>> processed error
On Wed, Jul 01, 2020 at 10:24:29PM +0900, Tetsuo Handa wrote:
> On 2020/07/01 19:08, Christian Borntraeger wrote:
> >
> >
> > On 30.06.20 19:57, Luis Chamberlain wrote:
> >> On Fri, Jun 26, 2020 at 02:54:10AM +, Luis Chamberlain wrote:
> >>> On Wed, Jun 24, 2020 at 08:37:55PM +0200,
On Wed, Jul 01, 2020 at 12:08:11PM +0200, Christian Borntraeger wrote:
> dmesg attached
> [ 14.438482] virbr0: port 1(virbr0-nic) entered blocking state
> [ 14.438485] virbr0: port 1(virbr0-nic) entered disabled state
> [ 14.438635] device virbr0-nic entered promiscuous mode
> [ 14.439654]
On 2020/07/01 19:08, Christian Borntraeger wrote:
>
>
> On 30.06.20 19:57, Luis Chamberlain wrote:
>> On Fri, Jun 26, 2020 at 02:54:10AM +, Luis Chamberlain wrote:
>>> On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
On 24.06.20 20:32, Christian
On 30.06.20 19:57, Luis Chamberlain wrote:
> On Fri, Jun 26, 2020 at 02:54:10AM +, Luis Chamberlain wrote:
>> On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
>>>
>>>
>>> On 24.06.20 20:32, Christian Borntraeger wrote:
>>> [...]>
So the translations look correct.
On Fri, Jun 26, 2020 at 02:54:10AM +, Luis Chamberlain wrote:
> On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
> >
> >
> > On 24.06.20 20:32, Christian Borntraeger wrote:
> > [...]>
> > > So the translations look correct. But your change is actually a sematic
> > >
On Fri, Jun 26, 2020 at 11:40:08AM +, Luis Chamberlain wrote:
> Andrew, can you please revert these two for now:
>
> selftests: simplify kmod failure value
> umh: fix processed error when UMH_WAIT_PROC is used
>
> Later, we'll add Christoph's simplier kernel wait, and make the change
>
On Fri, Jun 26, 2020 at 10:00:01AM +0100, Christoph Hellwig wrote:
> On Fri, Jun 26, 2020 at 07:22:34AM +0200, Christian Borntraeger wrote:
> >
> >
> > On 26.06.20 04:54, Luis Chamberlain wrote:
> > > On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
> > >>
> > >>
> > >> On
On Fri, Jun 26, 2020 at 07:22:34AM +0200, Christian Borntraeger wrote:
>
>
> On 26.06.20 04:54, Luis Chamberlain wrote:
> > On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
> >>
> >>
> >> On 24.06.20 20:32, Christian Borntraeger wrote:
> >> [...]>
> >>> So the translations
On 26.06.20 04:54, Luis Chamberlain wrote:
> On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
>>
>>
>> On 24.06.20 20:32, Christian Borntraeger wrote:
>> [...]>
>>> So the translations look correct. But your change is actually a sematic
>>> change
>>> if(ret) will only
On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
>
>
> On 24.06.20 20:32, Christian Borntraeger wrote:
> [...]>
> > So the translations look correct. But your change is actually a sematic
> > change
> > if(ret) will only trigger if there is an error
> > if
On 24.06.20 20:37, Christian Borntraeger wrote:
>
>
> On 24.06.20 20:32, Christian Borntraeger wrote:
> [...]>
>> So the translations look correct. But your change is actually a sematic
>> change
>> if(ret) will only trigger if there is an error
>> if (KWIFEXITED(ret)) will always trigger
On 24.06.20 20:32, Christian Borntraeger wrote:
[...]>
> So the translations look correct. But your change is actually a sematic change
> if(ret) will only trigger if there is an error
> if (KWIFEXITED(ret)) will always trigger when the process ends. So we will
> always overwrite -ECHILD
>
On 24.06.20 20:09, Christian Borntraeger wrote:
>
>
> On 24.06.20 19:58, Christian Borntraeger wrote:
>>
>>
>> On 24.06.20 18:09, Luis Chamberlain wrote:
>>> On Wed, Jun 24, 2020 at 05:54:46PM +0200, Christian Borntraeger wrote:
On 24.06.20 16:43, Christoph Hellwig wrote:
>
On 24.06.20 19:58, Christian Borntraeger wrote:
>
>
> On 24.06.20 18:09, Luis Chamberlain wrote:
>> On Wed, Jun 24, 2020 at 05:54:46PM +0200, Christian Borntraeger wrote:
>>>
>>>
>>> On 24.06.20 16:43, Christoph Hellwig wrote:
On Wed, Jun 24, 2020 at 01:11:54PM +0200, Christian
On 24.06.20 18:09, Luis Chamberlain wrote:
> On Wed, Jun 24, 2020 at 05:54:46PM +0200, Christian Borntraeger wrote:
>>
>>
>> On 24.06.20 16:43, Christoph Hellwig wrote:
>>> On Wed, Jun 24, 2020 at 01:11:54PM +0200, Christian Borntraeger wrote:
Does anyone have an idea why "umh: fix
On Wed, Jun 24, 2020 at 01:17:25PM +, Luis Chamberlain wrote:
> I found however an LTP bug indicating the need to test for
> s390 wait macros [0] in light of a recent bug in glibc for s390.
> I am asking for references to that issue given I cannot find
> any mention of this on glibc yet.
>
>
On Wed, Jun 24, 2020 at 05:54:46PM +0200, Christian Borntraeger wrote:
>
>
> On 24.06.20 16:43, Christoph Hellwig wrote:
> > On Wed, Jun 24, 2020 at 01:11:54PM +0200, Christian Borntraeger wrote:
> >> Does anyone have an idea why "umh: fix processed error when UMH_WAIT_PROC
> >> is used" breaks
On 24.06.20 16:43, Christoph Hellwig wrote:
> On Wed, Jun 24, 2020 at 01:11:54PM +0200, Christian Borntraeger wrote:
>> Does anyone have an idea why "umh: fix processed error when UMH_WAIT_PROC is
>> used" breaks the
>> linux-bridge on s390?
>
> Are we even sure this is s390 specific and
On Wed, Jun 24, 2020 at 01:11:54PM +0200, Christian Borntraeger wrote:
> Does anyone have an idea why "umh: fix processed error when UMH_WAIT_PROC is
> used" breaks the
> linux-bridge on s390?
Are we even sure this is s390 specific and doesn't happen on other
architectures with the same bridge
Martin, your eyeballs would be appreciated for a bit on this.
On Wed, Jun 24, 2020 at 12:05:46PM +, Luis Chamberlain wrote:
> On Wed, Jun 24, 2020 at 01:11:54PM +0200, Christian Borntraeger wrote:
> >
> >
> > On 23.06.20 16:23, Christian Borntraeger wrote:
> > >
> > >
> > > On 23.06.20
On Wed, Jun 24, 2020 at 01:11:54PM +0200, Christian Borntraeger wrote:
>
>
> On 23.06.20 16:23, Christian Borntraeger wrote:
> >
> >
> > On 23.06.20 16:11, Christian Borntraeger wrote:
> >> Jens Markwardt reported a regression in the linux-next runs. with "umh:
> >> fix
> >> processed error
On 23.06.20 16:23, Christian Borntraeger wrote:
>
>
> On 23.06.20 16:11, Christian Borntraeger wrote:
>> Jens Markwardt reported a regression in the linux-next runs. with "umh: fix
>> processed error when UMH_WAIT_PROC is used" (from linux-next) a linux bridge
>> with an KVM guests no longer
On 23.06.20 16:11, Christian Borntraeger wrote:
> Jens Markwardt reported a regression in the linux-next runs. with "umh: fix
> processed error when UMH_WAIT_PROC is used" (from linux-next) a linux bridge
> with an KVM guests no longer activates :
>
> without patch
> # ip addr show dev virbr1
33 matches
Mail list logo
