[PATCH v1 03/11] fs/proc/vmcore: disallow vmcore modifications after the vmcore was opened
Baoquan He
bhe at redhat.com
Fri Nov 22 01:16:45 PST 2024
On 10/25/24 at 05:11pm, David Hildenbrand wrote:
......snip...
> @@ -1482,6 +1470,10 @@ int vmcore_add_device_dump(struct vmcoredd_data *data)
> return -EINVAL;
> }
>
> + /* We'll recheck under lock later. */
> + if (data_race(vmcore_opened))
> + return -EBUSY;
As I commented to patch 7, if vmcore is opened and closed after
checking, do we need to give up any chance to add device dumping
as below?
fd = open(/proc/vmcore);
...do checking;
close(fd);
quit any device dump adding;
run makedumpfile on s390;
->fd = open(/proc/vmcore);
-> try to dump;
->close(fd);
> +
> if (!data || !strlen(data->dump_name) ||
> !data->vmcoredd_callback || !data->size)
> return -EINVAL;
> @@ -1515,12 +1507,16 @@ int vmcore_add_device_dump(struct vmcoredd_data *data)
> dump->buf = buf;
> dump->size = data_size;
>
> - /* Add the dump to driver sysfs list */
> + /* Add the dump to driver sysfs list and update the elfcore hdr */
> mutex_lock(&vmcore_mutex);
> - list_add_tail(&dump->list, &vmcoredd_list);
> - mutex_unlock(&vmcore_mutex);
> + if (vmcore_opened) {
> + ret = -EBUSY;
> + goto out_err;
> + }
>
> + list_add_tail(&dump->list, &vmcoredd_list);
> vmcoredd_update_size(data_size);
> + mutex_unlock(&vmcore_mutex);
> return 0;
>
> out_err:
> --
> 2.46.1
>
More information about the kexec
mailing list