On 23-07-18, 16:53, Srinivas Kandagatla wrote:
> Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC, supports
> Qualcomm Technologies, Inc. (QTI) multimedia solutions, including
> the MSM8996, MSM8976, and MSM8956 chipsets. It has in-build
in-built perhaps?
--
~Vinod
On July 23, 2018 10:49:15 PM GMT+02:00, Lucas Stach wrote:
>Am Freitag, den 20.07.2018, 09:55 +0200 schrieb Marcel Ziswiler:
>> From: Marcel Ziswiler
>>
>> Actually report the error code from devm_regulator_get() which may as
>> well just be a probe deferral.
>
>This is still noisy, so while
On 23-07-18, 16:53, Srinivas Kandagatla wrote:
> Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC, supports
> Qualcomm Technologies, Inc. (QTI) multimedia solutions, including
> the MSM8996, MSM8976, and MSM8956 chipsets. It has in-build
in-built perhaps?
--
~Vinod
On July 23, 2018 10:49:15 PM GMT+02:00, Lucas Stach wrote:
>Am Freitag, den 20.07.2018, 09:55 +0200 schrieb Marcel Ziswiler:
>> From: Marcel Ziswiler
>>
>> Actually report the error code from devm_regulator_get() which may as
>> well just be a probe deferral.
>
>This is still noisy, so while
Because our fuzzer has a problem, I don't have a C reproducer so far.
I reported the crash becasue I saw the crash repeatedly in our fuzzer and I
hoped the report is helpful. But it seems not enough.
If I was wrong and I made you confused, I am really sorry for that.
Could you give me a second?
I
Because our fuzzer has a problem, I don't have a C reproducer so far.
I reported the crash becasue I saw the crash repeatedly in our fuzzer and I
hoped the report is helpful. But it seems not enough.
If I was wrong and I made you confused, I am really sorry for that.
Could you give me a second?
I
On 23-07-18, 16:53, Srinivas Kandagatla wrote:
> Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC.
> It is integrated in multiple Qualcomm SoCs like: MSM8996, MSM8976,
> and MSM8956 chipsets.
>
> WCD9335 had multiple functional blocks, like: Soundwire controller,
> interrupt mux, pin
On 23-07-18, 16:53, Srinivas Kandagatla wrote:
> Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC.
> It is integrated in multiple Qualcomm SoCs like: MSM8996, MSM8976,
> and MSM8956 chipsets.
>
> WCD9335 had multiple functional blocks, like: Soundwire controller,
> interrupt mux, pin
> mmc_select_hs400es() calls mmc_select_bus_width() which will continue
> to set 4bit transfer mode if fail to set 8bit mode. The bus width
> should not be set to 4bit in HS400es.
>
> When fail to set 8bit mode, need return error directly for HS400es.
>
> Signed-off-by: Hongjie Fang
> ---
>
> mmc_select_hs400es() calls mmc_select_bus_width() which will continue
> to set 4bit transfer mode if fail to set 8bit mode. The bus width
> should not be set to 4bit in HS400es.
>
> When fail to set 8bit mode, need return error directly for HS400es.
>
> Signed-off-by: Hongjie Fang
> ---
>
On Sun, 22 Jul 2018 16:28:52 -0700
Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix 2 printk format warnings (this driver is currently only used by
> arch/sh/) by using "%pap" instead of "%lx".
> (or we could just cast the physical addresses to unsigned int)
>
> Fixes these build warnings:
>
On Sun, 22 Jul 2018 16:28:52 -0700
Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix 2 printk format warnings (this driver is currently only used by
> arch/sh/) by using "%pap" instead of "%lx".
> (or we could just cast the physical addresses to unsigned int)
>
> Fixes these build warnings:
>
On Mon, Jul 23, 2018 at 04:23:39PM -0500, Richard Kuo wrote:
>
> On Mon, Jul 16, 2018 at 10:43:18AM +0300, Mike Rapoport wrote:
> > This patch adds registration of the system memory with memblock, eliminates
> > bootmem initialization and converts early memory reservations from bootmem
> > to
On Mon, Jul 23, 2018 at 04:23:39PM -0500, Richard Kuo wrote:
>
> On Mon, Jul 16, 2018 at 10:43:18AM +0300, Mike Rapoport wrote:
> > This patch adds registration of the system memory with memblock, eliminates
> > bootmem initialization and converts early memory reservations from bootmem
> > to
Hi Rob
On Fri, 20 Jul 2018 09:15:29 -0600 Rob Herring wrote:
> On Fri, Jul 13, 2018 at 05:24:57PM +0800, Jisheng Zhang wrote:
> > The AS370 SoC is a new derivative of the berlin family. The only
> > difference is the SoC isn't named as berlin*.
>
> So is it a derivative or just rebranded?
A
Hi Rob
On Fri, 20 Jul 2018 09:15:29 -0600 Rob Herring wrote:
> On Fri, Jul 13, 2018 at 05:24:57PM +0800, Jisheng Zhang wrote:
> > The AS370 SoC is a new derivative of the berlin family. The only
> > difference is the SoC isn't named as berlin*.
>
> So is it a derivative or just rebranded?
A
This converts FSI sbefifo to use the new fsi-core controlled
chardev allocator and use a real cdev instead of a miscdev.
One side effect is to fix the object lifetime by removing
the use of devm_kzalloc() for something that contains kobjects,
and using proper reference counting.
Signed-off-by:
This converts FSI sbefifo to use the new fsi-core controlled
chardev allocator and use a real cdev instead of a miscdev.
One side effect is to fix the object lifetime by removing
the use of devm_kzalloc() for something that contains kobjects,
and using proper reference counting.
Signed-off-by:
On Tue, Jul 24, 2018 at 01:21:17AM +0300, Georgios Tsotsos wrote:
> Signed-off-by: Georgios Tsotsos
> ---
> drivers/staging/octeon-usb/octeon-hcd.c | 55
> ++---
> drivers/staging/octeon-usb/octeon-hcd.h | 1 +
Hi,
This is the friendly patch-bot of Greg
On Tue, Jul 24, 2018 at 01:21:17AM +0300, Georgios Tsotsos wrote:
> Signed-off-by: Georgios Tsotsos
> ---
> drivers/staging/octeon-usb/octeon-hcd.c | 55
> ++---
> drivers/staging/octeon-usb/octeon-hcd.h | 1 +
Hi,
This is the friendly patch-bot of Greg
On Tue, Jul 24, 2018 at 06:17:26AM +0100, Al Viro wrote:
> On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote:
> > Diagnosis:
> > We think that it is possible that link_path_walk() dereferences a
> > freed pointer when cleanup_mnt() is executed between path_init() and
> >
On Tue, Jul 24, 2018 at 06:17:26AM +0100, Al Viro wrote:
> On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote:
> > Diagnosis:
> > We think that it is possible that link_path_walk() dereferences a
> > freed pointer when cleanup_mnt() is executed between path_init() and
> >
On Mon, Jul 23, 2018 at 8:42 PM, Fenghua Yu wrote:
> On Mon, Jul 23, 2018 at 06:48:00PM -0700, Andy Lutomirski wrote:
>> On 07/23/2018 05:55 AM, Fenghua Yu wrote:
>> >The instructions can be implemented in intrinsic functions in future
>> >GCC. But the vDSO interfaces are available to user
On Mon, Jul 23, 2018 at 8:42 PM, Fenghua Yu wrote:
> On Mon, Jul 23, 2018 at 06:48:00PM -0700, Andy Lutomirski wrote:
>> On 07/23/2018 05:55 AM, Fenghua Yu wrote:
>> >The instructions can be implemented in intrinsic functions in future
>> >GCC. But the vDSO interfaces are available to user
The bus scanning process isn't terribly good at parallel attempts
at rescanning the same bus. Let's have a per-master mutex protecting
the scanning process.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-core.c | 16 ++--
drivers/fsi/fsi-master.h | 2 ++
2 files
The bus scanning process isn't terribly good at parallel attempts
at rescanning the same bus. Let's have a per-master mutex protecting
the scanning process.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-core.c | 16 ++--
drivers/fsi/fsi-master.h | 2 ++
2 files
This aims to deprecate the "raw" sysfs file used for directly
accessing the CFAM and instead use a char device like the
other sub drivers.
Since it reworks the slave creation code and adds a cfam device
type, we also use the opportunity to convert the attributes
to attribute groups and add a
This aims to deprecate the "raw" sysfs file used for directly
accessing the CFAM and instead use a char device like the
other sub drivers.
Since it reworks the slave creation code and adds a cfam device
type, we also use the opportunity to convert the attributes
to attribute groups and add a
On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote:
> Diagnosis:
> We think that it is possible that link_path_walk() dereferences a
> freed pointer when cleanup_mnt() is executed between path_init() and
> link_path_walk().
>
> Since I'm not an expert on a file system and don't fully
On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote:
> Diagnosis:
> We think that it is possible that link_path_walk() dereferences a
> freed pointer when cleanup_mnt() is executed between path_init() and
> link_path_walk().
>
> Since I'm not an expert on a file system and don't fully
The various FSI devices (sbefifo, occ, scom, more to come)
currently use misc devices.
This is problematic as the minor device space for misc is
limited and there can be a lot of them. Also it limits our
ability to move them to a dedicated /dev/fsi directory or
to be smart about device naming and
This converts FSI scom to use the new fsi-core controlled
chardev allocator and use a real cdev instead of a miscdev.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-scom.c | 130 +
1 file changed, 80 insertions(+), 50 deletions(-)
diff --git
This converts the various FSI devices from misc dev to chardev,
as there can potentially be too much of them for misc devs limited
minors, and because there are some lifetime issues with the current
support.
This provide a common infrastructure to allocate an FSI major and
distribute minors in a
The various FSI devices (sbefifo, occ, scom, more to come)
currently use misc devices.
This is problematic as the minor device space for misc is
limited and there can be a lot of them. Also it limits our
ability to move them to a dedicated /dev/fsi directory or
to be smart about device naming and
This converts FSI scom to use the new fsi-core controlled
chardev allocator and use a real cdev instead of a miscdev.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-scom.c | 130 +
1 file changed, 80 insertions(+), 50 deletions(-)
diff --git
This converts the various FSI devices from misc dev to chardev,
as there can potentially be too much of them for misc devs limited
minors, and because there are some lifetime issues with the current
support.
This provide a common infrastructure to allocate an FSI major and
distribute minors in a
On Mon, 23 Jul 2018, Randy Dunlap wrote:
> On 07/20/2018 12:20 AM, Andreas Schwab wrote:
> > On Jul 19 2018, Randy Dunlap wrote:
> >
> >> block/partitions/ldm.o: In function `ldm_partition':
> >> ldm.c:(.text+0x1900): undefined reference to `strcmp'
> >> ldm.c:(.text+0x1964): undefined
On Mon, 23 Jul 2018, Randy Dunlap wrote:
> On 07/20/2018 12:20 AM, Andreas Schwab wrote:
> > On Jul 19 2018, Randy Dunlap wrote:
> >
> >> block/partitions/ldm.o: In function `ldm_partition':
> >> ldm.c:(.text+0x1900): undefined reference to `strcmp'
> >> ldm.c:(.text+0x1964): undefined
--
Greetings,
There is an urgent matter and mutual offer i would want to bring to your
attention privately and i would appreciate your swift response here
(xu.shiq...@aol.com) for further communication.
Await your swift response.
Regards,
--
Greetings,
There is an urgent matter and mutual offer i would want to bring to your
attention privately and i would appreciate your swift response here
(xu.shiq...@aol.com) for further communication.
Await your swift response.
Regards,
Hi Greg !
This adds support for offloading the FSI low level bitbanging to the
ColdFire coprocessor of the Aspeed SoCs. All the pre-requisites have
already been merged, this is the final piece in the puzzle.
This branch also pull gpio/ib-aspeed which is a topic branch already
in gpio/for-next
Hi Greg !
This adds support for offloading the FSI low level bitbanging to the
ColdFire coprocessor of the Aspeed SoCs. All the pre-requisites have
already been merged, this is the final piece in the puzzle.
This branch also pull gpio/ib-aspeed which is a topic branch already
in gpio/for-next
I think that below two crashes are also related to the same race issue.
KASAN: use-after-free Read in nd_jump_root, found in v4.17-rc1
KASAN: use-after-free in set_root, found in v4.18-rc3
==
BUG: KASAN: use-after-free in
I think that below two crashes are also related to the same race issue.
KASAN: use-after-free Read in nd_jump_root, found in v4.17-rc1
KASAN: use-after-free in set_root, found in v4.18-rc3
==
BUG: KASAN: use-after-free in
Hi,
On Tuesday 17 July 2018 04:57 PM, Kunihiko Hayashi wrote:
> Hi Kishon,
>
> On Fri, 13 Jul 2018 12:45:06 +0530 wrote:
>
>> Hi,
>>
>> On Wednesday 11 July 2018 05:35 PM, Kunihiko Hayashi wrote:
>>> On Mon, 9 Jul 2018 20:23:19 +0900 wrote:
>>>
Hi Kishon,
Thank you for your
Hi,
On Tuesday 17 July 2018 04:57 PM, Kunihiko Hayashi wrote:
> Hi Kishon,
>
> On Fri, 13 Jul 2018 12:45:06 +0530 wrote:
>
>> Hi,
>>
>> On Wednesday 11 July 2018 05:35 PM, Kunihiko Hayashi wrote:
>>> On Mon, 9 Jul 2018 20:23:19 +0900 wrote:
>>>
Hi Kishon,
Thank you for your
I just realized that the crash has been spotted by Syzkaller a few days before.
(https://syzkaller.appspot.com/bug?id=3490860a465e6b39227c6906f0ef2d40ad4d5bb1)
I'm CC'ing Syzkaller's mailing list.
Best regards,
DaeRyong Jeong
On Tue, Jul 24, 2018 at 12:36 PM, Dae R. Jeong wrote:
> Reporting
I just realized that the crash has been spotted by Syzkaller a few days before.
(https://syzkaller.appspot.com/bug?id=3490860a465e6b39227c6906f0ef2d40ad4d5bb1)
I'm CC'ing Syzkaller's mailing list.
Best regards,
DaeRyong Jeong
On Tue, Jul 24, 2018 at 12:36 PM, Dae R. Jeong wrote:
> Reporting
Hi,
On Friday 20 July 2018 06:11 PM, Scott Telford wrote:
> Add driver for the Cadence SD0801 "Torrent" PHY used with the Cadence MHDP
> DisplayPort Tx controller.
>
> Integration with the MHDP driver will be the subject of another commit.
>
> Signed-off-by: Scott Telford
> ---
>
Hi,
On Friday 20 July 2018 06:11 PM, Scott Telford wrote:
> Add driver for the Cadence SD0801 "Torrent" PHY used with the Cadence MHDP
> DisplayPort Tx controller.
>
> Integration with the MHDP driver will be the subject of another commit.
>
> Signed-off-by: Scott Telford
> ---
>
Reporting the crash: KASAN: use-after-free Read in link_path_walk
This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report. Our analysis shows that the race occurs when invoking two
syscalls concurrently, open()
Reporting the crash: KASAN: use-after-free Read in link_path_walk
This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report. Our analysis shows that the race occurs when invoking two
syscalls concurrently, open()
On 23-07-18, 20:34, YueHaibing wrote:
> Make sure of_device_id tables are NULL terminated
> Found by coccinelle spatch "misc/of_table.cocci"
>
> Signed-off-by: YueHaibing
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On Mon, Jul 23, 2018 at 06:48:00PM -0700, Andy Lutomirski wrote:
> On 07/23/2018 05:55 AM, Fenghua Yu wrote:
> >The instructions can be implemented in intrinsic functions in future
> >GCC. But the vDSO interfaces are available to user without the
> I'm not convinced that any of this belongs in the
On 23-07-18, 20:34, YueHaibing wrote:
> Make sure of_device_id tables are NULL terminated
> Found by coccinelle spatch "misc/of_table.cocci"
>
> Signed-off-by: YueHaibing
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On Mon, Jul 23, 2018 at 06:48:00PM -0700, Andy Lutomirski wrote:
> On 07/23/2018 05:55 AM, Fenghua Yu wrote:
> >The instructions can be implemented in intrinsic functions in future
> >GCC. But the vDSO interfaces are available to user without the
> I'm not convinced that any of this belongs in the
Reporting the crash: WARNING in port_delete
This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
version of Syzkaller), which we descrbie more at the end of this
report. Our analysis shows that the race occurs when invoking two close
syscalls concurrently.
The executed program is
Reporting the crash: WARNING in port_delete
This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
version of Syzkaller), which we descrbie more at the end of this
report. Our analysis shows that the race occurs when invoking two close
syscalls concurrently.
The executed program is
Hi Oleg,
On 07/23/2018 09:56 PM, Oleg Nesterov wrote:
> I have a mixed feeling about this series... I'll try to summarise my thinking
> tomorrow, but I do not see any obvious problem so far. Although I have some
> concerns about 5/6, I need to re-read it after sleep.
Sure.
>
>
> On 07/16,
Hi Oleg,
On 07/23/2018 09:56 PM, Oleg Nesterov wrote:
> I have a mixed feeling about this series... I'll try to summarise my thinking
> tomorrow, but I do not see any obvious problem so far. Although I have some
> concerns about 5/6, I need to re-read it after sleep.
Sure.
>
>
> On 07/16,
Hi,
On Mon, Jul 23, 2018 at 7:22 PM, Taniya Das wrote:
>
>
> On 7/24/2018 3:24 AM, Douglas Anderson wrote:
>>
>> Add both the interface and core clock.
>>
>> Signed-off-by: Douglas Anderson
>> ---
>>
>> Changes in v2:
>> - Only 19.2, 100, 150, and 300 MHz now.
>> - All clocks come from MAIN
Hi,
On Mon, Jul 23, 2018 at 7:22 PM, Taniya Das wrote:
>
>
> On 7/24/2018 3:24 AM, Douglas Anderson wrote:
>>
>> Add both the interface and core clock.
>>
>> Signed-off-by: Douglas Anderson
>> ---
>>
>> Changes in v2:
>> - Only 19.2, 100, 150, and 300 MHz now.
>> - All clocks come from MAIN
There are only two signals that are delivered to every member of a
signal group: SIGSTOP and SIGKILL. Signal delivery requires every
signal appear to be delivered either before or after a clone syscall.
SIGKILL terminates the clone so does not need to be considered. Which
leaves only SIGSTOP
This is the bottom and by pushing this down it simplifies the callers
and otherwise leaves things as is. This is in preparation for allowing
fork to implement better handling of signals set to groups of processes.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 8
1 file
This information is already available in the callers and by pushing it
down it makes the code a little clearer, and allows implementing
better handling of signales set to a group of processes in fork.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 12 ++--
1 file changed, 6
This information is already available in the callers and by pushing it
down it makes the code a little clearer, and allows better group
signal behavior in fork.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
Normally this would be something that would be handled by handling
signals that are sent to a group of processes but in this case the
forking process is not a member of the group being signaled. Thus
special code is needed to prevent a race with pid namespaces exiting,
and fork adding new
There are only two signals that are delivered to every member of a
signal group: SIGSTOP and SIGKILL. Signal delivery requires every
signal appear to be delivered either before or after a clone syscall.
SIGKILL terminates the clone so does not need to be considered. Which
leaves only SIGSTOP
This is the bottom and by pushing this down it simplifies the callers
and otherwise leaves things as is. This is in preparation for allowing
fork to implement better handling of signals set to groups of processes.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 8
1 file
This information is already available in the callers and by pushing it
down it makes the code a little clearer, and allows implementing
better handling of signales set to a group of processes in fork.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 12 ++--
1 file changed, 6
This information is already available in the callers and by pushing it
down it makes the code a little clearer, and allows better group
signal behavior in fork.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
Normally this would be something that would be handled by handling
signals that are sent to a group of processes but in this case the
forking process is not a member of the group being signaled. Thus
special code is needed to prevent a race with pid namespaces exiting,
and fork adding new
This information is already present and using it directly simplifies the logic
of the code.
Signed-off-by: "Eric W. Biederman"
---
fs/fcntl.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 1523588fd759..5d596a00f40b
This information is already present and using it directly simplifies the logic
of the code.
Signed-off-by: "Eric W. Biederman"
---
fs/fcntl.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 1523588fd759..5d596a00f40b
Wen Yang and majiang
report that a periodic signal received during fork can cause fork to
continually restart preventing an application from making progress.
The code was being overly pesimistic. Fork needs to guarantee that a
signal sent to multiple processes is logically delivered before the
Wen Yang and majiang
report that a periodic signal received during fork can cause fork to
continually restart preventing an application from making progress.
The code was being overly pesimistic. Fork needs to guarantee that a
signal sent to multiple processes is logically delivered before the
This passes the information we already have at the call sight into
do_send_sig_info. Ultimately allowing for better handling of signals
sent to a group of processes during fork.
Signed-off-by: "Eric W. Biederman"
---
drivers/tty/sysrq.c| 2 +-
fs/fcntl.c | 6 +++---
Add a function calculate_sigpending to test to see if any signals are
pending for a new task immediately following fork. Signals have to
happen either before or after fork. Today our practice is to push
all of the signals to before the fork, but that has the downside that
frequent or periodic
In practice this does not change anything as testing for fatal_signal_pending
and exiting for with an error code duplicates the work of the next clause
which recalculates pending signals and then exits fork if any are pending.
In both cases the pending signal will trigger the slow path when
This passes the information we already have at the call sight into
do_send_sig_info. Ultimately allowing for better handling of signals
sent to a group of processes during fork.
Signed-off-by: "Eric W. Biederman"
---
drivers/tty/sysrq.c| 2 +-
fs/fcntl.c | 6 +++---
Add a function calculate_sigpending to test to see if any signals are
pending for a new task immediately following fork. Signals have to
happen either before or after fork. Today our practice is to push
all of the signals to before the fork, but that has the downside that
frequent or periodic
In practice this does not change anything as testing for fatal_signal_pending
and exiting for with an error code duplicates the work of the next clause
which recalculates pending signals and then exits fork if any are pending.
In both cases the pending signal will trigger the slow path when
In good_sigevent directly compute the default return value as
"task_tgid(current)". This is exactly the same as
"task_pid(current->group_leader)" but written more clearly.
In the thread case first compute the thread's pid. Then veify that
attached to that pid is a thread of the current thread
When f_setown is called a pid and a pid type are stored. Replace the use
of PIDTYPE_PID with PIDTYPE_TGID as PIDTYPE_TGID goes to the entire thread
group. Replace the use of PIDTYPE_MAX with PIDTYPE_PID as PIDTYPE_PID now
is only for a thread.
Update the users of __f_setown to use PIDTYPE_TGID
In good_sigevent directly compute the default return value as
"task_tgid(current)". This is exactly the same as
"task_pid(current->group_leader)" but written more clearly.
In the thread case first compute the thread's pid. Then veify that
attached to that pid is a thread of the current thread
When f_setown is called a pid and a pid type are stored. Replace the use
of PIDTYPE_PID with PIDTYPE_TGID as PIDTYPE_TGID goes to the entire thread
group. Replace the use of PIDTYPE_MAX with PIDTYPE_PID as PIDTYPE_PID now
is only for a thread.
Update the users of __f_setown to use PIDTYPE_TGID
Make the code more maintainable by performing more of the signal
related work in send_sigqueue.
A quick inspection of do_timer_create will show that this code path
does not lookup a thread group by a thread's pid. Making it safe
to find the task pointed to by it_pid with "pid_task(it_pid,
Everywhere except in the pid array we distinguish between a tasks pid and
a tasks tgid (thread group id). Even in the enumeration we want that
distinction sometimes so we have added __PIDTYPE_TGID. With leader_pid
we almost have an implementation of PIDTYPE_TGID in struct signal_struct.
Add
This passes the information we already have at the call sight
into group_send_sig_info. Ultimatelly allowing for to better handle
signals sent to a group of processes.
Signed-off-by: "Eric W. Biederman"
---
include/linux/signal.h | 4 +++-
kernel/exit.c | 3 ++-
kernel/signal.c
Make the code more maintainable by performing more of the signal
related work in send_sigqueue.
A quick inspection of do_timer_create will show that this code path
does not lookup a thread group by a thread's pid. Making it safe
to find the task pointed to by it_pid with "pid_task(it_pid,
Everywhere except in the pid array we distinguish between a tasks pid and
a tasks tgid (thread group id). Even in the enumeration we want that
distinction sometimes so we have added __PIDTYPE_TGID. With leader_pid
we almost have an implementation of PIDTYPE_TGID in struct signal_struct.
Add
This passes the information we already have at the call sight
into group_send_sig_info. Ultimatelly allowing for to better handle
signals sent to a group of processes.
Signed-off-by: "Eric W. Biederman"
---
include/linux/signal.h | 4 +++-
kernel/exit.c | 3 ++-
kernel/signal.c
This is cheap and no cost so we might as well.
Signed-off-by: "Eric W. Biederman"
---
init/init_task.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/init/init_task.c b/init/init_task.c
index 74f60baa2799..7914ffb8dc73 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -33,6 +33,7 @@
The function is general and inline so there is no need
to hide it inside of exit.c
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8
kernel/exit.c| 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git
This is cheap and no cost so we might as well.
Signed-off-by: "Eric W. Biederman"
---
init/init_task.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/init/init_task.c b/init/init_task.c
index 74f60baa2799..7914ffb8dc73 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -33,6 +33,7 @@
The function is general and inline so there is no need
to hide it inside of exit.c
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8
kernel/exit.c| 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git
The cost is the the same and this removes the need
to worry about complications that come from de_thread
and group_leader changing.
__task_pid_nr_ns has been updated to take advantage of this change.
Signed-off-by: "Eric W. Biederman"
---
arch/ia64/kernel/asm-offsets.c | 2 +-
To access these fields the code always has to go to group leader so
going to signal struct is no loss and is actually a fundamental simplification.
This saves a little bit of memory by only allocating the pid pointer array
once instead of once for every thread, and even better this removes a
few
Signed-off-by: "Eric W. Biederman"
---
virt/kvm/kvm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index ada21f47f22b..4c593acc4510 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2560,7 +2560,7 @@ static long
The cost is the the same and this removes the need
to worry about complications that come from de_thread
and group_leader changing.
__task_pid_nr_ns has been updated to take advantage of this change.
Signed-off-by: "Eric W. Biederman"
---
arch/ia64/kernel/asm-offsets.c | 2 +-
1 - 100 of 1916 matches
Mail list logo
