Re: [PATCH 10/11] pragma once: delete few backslashes
Hi!
> > index e201b4b1655a..46704c341b17 100644
> > --- a/arch/arc/include/asm/cacheflush.h
> > +++ b/arch/arc/include/asm/cacheflush.h
> > @@ -112,6 +112,6 @@ do {
> > \
> > } while (0)
> >
> > #define copy_from_user_page(vma, page, vaddr, dst, src, len)
> > \
> > - memcpy(dst, src, len); \
> > + memcpy(dst, src, len)
> > This changebar also removes a semicolon.
> It looks plausibly correct, but the commit message ought to mention it.
Probably should use do{}while(0) trick.
Pavel
--
http://www.livejournal.com/~pavelmachek
signature.asc
Description: Digital signature
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
On Fri 2018-03-30 12:07:58, Ilya Smith wrote: > Hi > > > On 30 Mar 2018, at 10:55, Pavel Machek <pa...@ucw.cz> wrote: > > > > Hi! > > > >> Current implementation doesn't randomize address returned by mmap. > >> All the entropy ends with choosing mmap_base_addr at the process > >> creation. After that mmap build very predictable layout of address > >> space. It allows to bypass ASLR in many cases. This patch make > >> randomization of address on any mmap call. > > > > How will this interact with people debugging their application, and > > getting different behaviours based on memory layout? > > > > strace, strace again, get different results? > > > > Honestly I’m confused about your question. If the only one way for debugging > application is to use predictable mmap behaviour, then something went wrong > in > this live and we should stop using computers at all. I'm not saying "only way". I'm saying one way, and you are breaking that. There's advanced stuff like debuggers going "back in time". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
Hi! > Current implementation doesn't randomize address returned by mmap. > All the entropy ends with choosing mmap_base_addr at the process > creation. After that mmap build very predictable layout of address > space. It allows to bypass ASLR in many cases. This patch make > randomization of address on any mmap call. How will this interact with people debugging their application, and getting different behaviours based on memory layout? strace, strace again, get different results? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] fix double ;;s in code
Hi!
> > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> > index 53f7275..cfb42f5 100644
> > --- a/drivers/soc/imx/gpc.c
> > +++ b/drivers/soc/imx/gpc.c
> > @@ -348,7 +348,7 @@ static int imx_gpc_old_dt_init(struct device *dev,
> > struct regmap *regmap,
> > if (i == 1) {
> > domain->supply = devm_regulator_get(dev, "pu");
> > if (IS_ERR(domain->supply))
> > - return PTR_ERR(domain->supply);;
> > + return PTR_ERR(domain->supply);
> >
> > ret = imx_pgc_get_clocks(dev, domain);
> > if (ret)
> >
>
> Considering the controversy how the changes should be merged, I'm going
> to send a separate patch just for IMX GPC driver with a reported-by-you
> tag. Thanks for catching this.
That works for me.
Alternatively... Andrew Morton merged the patch to his -mm tree
(thanks!), so you don't need to take any action, and it will be
eventually fixed.
If you merge your own version of the patch, that's ok, too, since
Andrew will just drop his version.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] fix double ;;s in code
On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
> On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
> >
> >
> > Le 17/02/2018 à 22:19, Pavel Machek a écrit :
> > >
> > > Fix double ;;'s in code.
> > >
> > > Signed-off-by: Pavel Machek <pa...@ucw.cz>
> >
> > A summary of the files modified on top of the patch would help understand
> > the impact.
> >
> > A maybe there should be one patch by area, eg one for each arch specific
> > modif and one for drivers/ and one for block/ ?
>
> Yeah, pls split this into one patch per area, with a suitable patch
> subject prefix. Look at git log of each file to get a feeling for what's
> the standard in each area.
Yeah I can spend hour spliting it, and then people will ignore it
anyway.
If you care about one of the files being modified, please fix the
bug, ";;" is a clear bug.
If you don't care ... well I don't care either.
drivers/gpu/ has four entries, i guess that's something for you.
Pavel
> > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > > b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > > index 61e8c3e..33d91e4 100644
> > > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > > @@ -718,7 +718,7 @@ static enum link_training_result
> > > perform_channel_equalization_sequence(
> > > uint32_t retries_ch_eq;
> > > enum dc_lane_count lane_count =
> > > lt_settings->link_settings.lane_count;
> > > union lane_align_status_updated dpcd_lane_status_updated =
> > > {{0}};
> > > - union lane_status dpcd_lane_status[LANE_COUNT_DP_MAX] = {{{0}}};;
> > > + union lane_status dpcd_lane_status[LANE_COUNT_DP_MAX] = {{{0}}};
> > > hw_tr_pattern = get_supported_tp(link);
> > > diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > > b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > > index 4c3223a..adb6e7b 100644
> > > --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > > +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > > @@ -162,7 +162,7 @@ static int pp_hw_init(void *handle)
> > > if(hwmgr->smumgr_funcs->start_smu(pp_handle->hwmgr)) {
> > > pr_err("smc start failed\n");
> > > hwmgr->smumgr_funcs->smu_fini(pp_handle->hwmgr);
> > > - return -EINVAL;;
> > > + return -EINVAL;
> > > }
> > > if (ret == PP_DPM_DISABLED)
> > > goto exit;
> > > diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> > > b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> > > index 3e9bba4..6d8e3a9 100644
> > > --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> > > +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> > > @@ -680,7 +680,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
> > > } else {
> > > dev_info(>dev,
> > >"no iommu, fallback to phys contig buffers for
> > > scanout\n");
> > > - aspace = NULL;;
> > > + aspace = NULL;
> > > }
> > > pm_runtime_put_sync(>dev);
> > > diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > index 2c18996..0d95888 100644
> > > --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > @@ -461,7 +461,7 @@ void drm_sched_hw_job_reset(struct drm_gpu_scheduler
> > > *sched, struct drm_sched_jo
> > > {
> > > struct drm_sched_job *s_job;
> > > struct drm_sched_entity *entity, *tmp;
> > > - int i;;
> > > + int i;
> > > spin_lock(>job_list_lock);
> > > list_for_each_entry_reverse(s_job, >ring_mirror_list,
> > > node) {
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: UDL's fbdev doesn't work for user-space apps
On Tue 2017-12-12 19:48:05, Alexey Brodkin wrote: > Hi Pavel, > > On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote: > > On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > > > > > > Hi Alexey, > > > > > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > > > > > > > My first [probably incorrect] assumption is Xserver requires fbdev > > > > (/dev/fbX) > > > > and it cannot use DRI video card natively. Is that correct? > > > > > > > > > > > > > > Xserver can use DRI directly, you need to enable modesetting > > > driver in Xorg config or use the designated driver for your card > > > (if there is any). > > > > Still, dev/fb1 should work. > > Agree, but it doesn't :) > Even on completely different architectures (ARC and ARM). Yeah, would be nice to get it fixed :-). I remember it did not work for me, either, and .. that's some time ago. Architecture probably plays no role there. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: UDL's fbdev doesn't work for user-space apps
On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > Hi Alexey, > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > My first [probably incorrect] assumption is Xserver requires fbdev > > (/dev/fbX) > > and it cannot use DRI video card natively. Is that correct? > > > > > > Xserver can use DRI directly, you need to enable modesetting > driver in Xorg config or use the designated driver for your card > (if there is any). Still, dev/fb1 should work. Can be tested using dd, even :-) Best regards, Pavel > > e.g.: > > Section "Device" > Identifier "Card0" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card0" > Option "SWcursor" "true" > BusID "PCI:X:X:X" > EndSection > > Best Regards, > Jose Miguel Abreu -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
